DEV Community: ramiro quintana

GitHub Student Developer Pack: What You Can Get as a Student

ramiro quintana — Fri, 25 Sep 2026 18:05:37 +0000

If you're a student learning software development, the GitHub Student Developer Pack is something you should probably know about.

It gives eligible students access to GitHub and a collection of developer tools and services from different partners, with some offers available for up to two years.

The interesting part is that it's much more than just GitHub Pro.

Depending on the current offers, students can get access to tools related to:

Cloud and infrastructure
Development environments
AI tools
Domains and hosting
Databases
APIs
Design
Security
Developer productivity

GitHub currently states that student verification lasts for two years, and students can re-verify their status afterward if they remain eligible.

I recently organized the information I found into a small open-source project:

GitHub Student Pack Guide

It's a guide to the benefits available through the Student Developer Pack, with the information organized by category to make it easier to find useful tools.

The repository is available in English, Spanish and Portuguese:

https://github.com/quintana-dev/github-student-pack-guide

I built this mainly because when you're starting out as a developer, it's easy to pay for tools without realizing that some of them may already be available through your student status.

If you're currently studying software development, it's worth checking what you have access to before paying for developer tools yourself.

About Me

I'm Ramiro Quintana, a Software Engineer & Full Stack Developer from Argentina.

I build web applications, browser extensions, automation tools and other software projects under quintana.dev.

I'm currently focused on software development, automation, web technologies and building practical projects while continuing to learn and improve.

You can find my projects and other work on my website:

https://quintana.dev.ar

How Hacktron Hacked OpenAI: What I Learned from an AI-Assisted Attack Chain

ramiro quintana — Mon, 21 Sep 2026 15:46:13 +0000

A few days ago, I came across a security research report from Hacktron that caught my attention.

The researchers described how they chained multiple vulnerabilities to compromise OpenAI employee accounts and reach internal GitHub repositories.

What makes the story particularly interesting isn't just the final impact.

It's the attack chain.

The initial vulnerability involved image processing. From there, the researchers were able to move through Discourse, OpenAI's authentication infrastructure, employee accounts, and connected GitHub integrations.

Even more interestingly, AI models were used throughout parts of the research process.

This made me want to break down the attack at a high level and understand what developers can learn from it.

Disclaimer: This is my analysis of publicly reported security research by Hacktron. I'm intentionally not reproducing exploit code, credentials, or instructions that could be used to compromise real systems.

The attack chain

The entire chain can be simplified to:

HEIF / HEIC image
        ↓
   ImageMagick
        ↓
     libheif
        ↓
Remote Code Execution
        ↓
     Discourse
        ↓
 OpenAI SSO issue
        ↓
Employee ChatGPT / Codex account
        ↓
 Connected GitHub integration
        ↓
 Internal repositories

The important part is that this wasn't a single vulnerability magically giving researchers access to OpenAI's internal repositories.

It was a chain of different trust boundaries.

Hacktron's published research describes the chain as involving a libheif image-decoding vulnerability, Debian's security backport situation, ImageMagick, Discourse image uploads, an OpenAI SSO issue, and eventually connected GitHub access. (Routley News)

And that's probably the biggest lesson from the whole story.

1. It started with an image upload

Image uploads are something developers deal with constantly.

You upload an image.

The application validates it.

Maybe it generates a thumbnail.

Maybe it converts the format.

Maybe it extracts metadata.

From the application's perspective, it can look like a simple feature.

But behind the scenes, an image might pass through several native libraries.

In this case, Hacktron focused on the processing of HEIF/HEIC images and the native libraries involved in decoding them.

The important detail is that the application itself didn't necessarily contain the vulnerable code.

A web application can depend on:

Application
    ↓
ImageMagick
    ↓
libheif
    ↓
libde265
    ↓
native C/C++ code

This creates a dependency chain that developers don't always think about when looking at their own source code.

According to Hacktron's research, the vulnerability in libheif could be leveraged during image processing to obtain remote code execution in the affected environment. (Routley News)

2. The dependency problem

This is one of the parts I found most interesting.

When we think about dependency security, we usually think about:

npm install package
        ↓
package vulnerability

But production software is often much deeper than that.

A project might use:

React
  ↓
Node package
  ↓
Native dependency
  ↓
System package
  ↓
C/C++ library

And vulnerabilities can exist several layers below the code we're actually writing.

Hacktron reported that the underlying libheif issue had previously been fixed upstream but had not gone through the usual security advisory process, meaning the vulnerable version could remain present in downstream environments. (SecurityWeek)

That creates an important distinction:

"The latest version of my application dependencies" doesn't necessarily mean "every component in my execution environment is secure."

Dependency management has to include the operating system, container images, native libraries and transitive dependencies.

3. Why Discourse mattered

The vulnerable image-processing path was exposed through Discourse, the software used by OpenAI's community forum.

That changed the situation significantly.

The vulnerability wasn't sitting on an isolated research machine.

It was reachable through a real application processing user-uploaded content.

The simplified model was:

Attacker-controlled file
        ↓
Discourse
        ↓
Image processing
        ↓
Vulnerable native library
        ↓
Code execution

This is a classic example of why file uploads should be treated as an attack surface.

An image isn't necessarily "just an image."

It's an input that may eventually be interpreted by complex native software.

4. RCE wasn't the end of the attack

This is where the research gets particularly interesting.

Getting remote code execution on one component doesn't automatically mean you have access to everything.

There are supposed to be boundaries:

Compromised server
       ✕
OpenAI employee account
       ✕
GitHub
       ✕
Internal repositories

The researchers found another weakness involving OpenAI's SSO flow.

According to Hacktron, this allowed the attack to move from the compromised forum environment toward employee ChatGPT/Codex accounts. (Routley News)

This is a good example of why identity systems are part of an application's security perimeter.

A vulnerability in one service can become much more serious if that service has a trusted relationship with an identity provider.

5. The importance of trust relationships

Imagine a system like this:

Community Forum
       │
       │ SSO
       ↓
OpenAI Account
       │
       │ OAuth / integration
       ↓
GitHub
       │
       ↓
Internal repositories

Every arrow represents a trust relationship.

If the first component is compromised, the attacker may try to abuse the trust relationships that follow.

This is why security reviews shouldn't only ask:

"Can an attacker compromise this application?"

They should also ask:

"What can an attacker reach if this application is compromised?"

That's a very different question.

6. Where AI entered the picture

Another part of the research received a lot of attention: the researchers used AI models during the investigation.

According to reporting on the research, Hacktron used Anthropic's Claude models to assist with analyzing the vulnerability and developing parts of the exploit. The researchers still performed the security research themselves, including adapting and validating the results. (The Verge)

This distinction matters.

This wasn't:

AI
 ↓
"hack OpenAI"
 ↓
done

It was closer to:

Security researchers
        ↓
AI-assisted analysis
        ↓
Hypotheses
        ↓
Testing
        ↓
Debugging
        ↓
Human validation
        ↓
Working research

AI can dramatically reduce the amount of time required to understand unfamiliar code, generate hypotheses, investigate libraries and iterate on technical problems.

But the researcher still needs to know what to ask, what to test and whether the result actually makes sense.

7. The most interesting lesson: attack chains

For me, this is the biggest takeaway.

If you looked at the individual components separately, the final impact would be difficult to predict.

You had:

Image processing vulnerability
+
Application exposure
+
SSO configuration issue
+
Employee account
+
GitHub integration

Together, they created something much more significant.

This is why vulnerability severity shouldn't always be considered in isolation.

A vulnerability that looks limited when viewed independently can become much more serious when combined with another weakness.

8. What developers can learn from this

There are several practical lessons here that apply far beyond OpenAI.

Treat file uploads as hostile input

Images, PDFs, archives and other files can trigger complex parsers.

Don't assume that because a file has a familiar extension, processing it is harmless.

Understand your dependency tree

Don't only track the libraries you explicitly installed.

Understand what your application ultimately depends on:

Application
    ↓
Framework
    ↓
Package
    ↓
Native library
    ↓
Operating system

Keep native dependencies updated

Libraries written in C/C++ are often extremely powerful because they operate close to the system.

They're also capable of memory-safety vulnerabilities.

Keeping them updated and isolating their execution can significantly reduce the impact of a compromise.

Minimize trust between services

If a community forum can somehow become a path toward employee accounts, that's a sign that the boundaries between systems deserve careful review.

Every integration should have the minimum privileges necessary.

Review SSO configurations carefully

Authentication isn't just about passwords.

SSO introduces relationships between different systems.

Those relationships need to be treated as security boundaries.

Assume compromised components will be used as stepping stones

A useful security question is:

"If this component is completely compromised, what can the attacker do next?"

That question can reveal problems that aren't obvious when reviewing each application independently.

9. AI changes the economics of security research

The part I find most interesting isn't necessarily that AI can write exploit code.

We've known for a while that models can generate code.

The bigger change is the speed of iteration.

Security research often involves:

Read code
   ↓
Understand behavior
   ↓
Form hypothesis
   ↓
Write test
   ↓
Observe result
   ↓
Debug
   ↓
Try again

AI can accelerate several of these steps.

That doesn't eliminate the need for expertise.

Instead, it potentially allows a small team to explore a much larger technical surface in a shorter amount of time.

And that applies to both sides.

The same tools can help defenders understand vulnerabilities, audit dependencies and investigate suspicious behavior.

Final thoughts

What started as an image-processing vulnerability ultimately became a much larger security problem because it could be chained across multiple systems.

That's what I found most interesting about Hacktron's research.

The lesson isn't simply:

"Image processing is dangerous."

It's:

Security is often about the connections between systems, not just the systems themselves.

A vulnerable library, a web application, an identity provider and a third-party integration might each look manageable on their own.

When they're connected, the security properties of the entire chain matter.

And as AI becomes better at assisting security researchers, understanding those chains may become even more important.

About me

I'm Ramiro Quintana, a Software Engineer & Full Stack Developer from Argentina.

I build web applications, browser extensions and software projects under quintana.dev.

I'm particularly interested in software engineering, automation, reverse engineering and cybersecurity.

You can find my projects and other technical posts on my website:

https://quintana.dev.ar

Sources

Hacktron's original security research on the OpenAI attack chain. (Routley News)
SecurityWeek's technical summary of the vulnerability chain and AI-assisted research. (SecurityWeek)
The Verge's reporting on Hacktron's research and the role of Claude. (The Verge)

How I Built Calculadora SIU CrediUPE: Automating Credit Calculation in SIU Guaraní

ramiro quintana — Mon, 14 Sep 2026 15:26:45 +0000

I'm Ramiro Quintana, a Software Engineer & Full Stack Developer. I built Calculadora SIU CrediUPE to solve a small but repetitive problem I encountered while using SIU Guaraní at Universidad Provincial de Ezeiza (UPE).

When checking my study plan, I wanted an easier way to keep track of how many free credits I had accumulated. The information was already available in the system, but calculating and filtering it manually was unnecessary work.

So I decided to automate it.

The idea

Calculadora SIU CrediUPE is a Chrome extension that works directly on the SIU Guaraní study plan. Its main purpose is to automatically calculate the number of free credits based on the information already displayed by the system.

What started as a small tool to solve a problem I had myself ended up being used by other students as well. Today, Calculadora SIU CrediUPE has surpassed 800 downloads and has more than 250 users.

Seeing other people use something I built to solve a specific problem has been one of the most rewarding parts of the project.

How it works

The extension works by interacting with the existing DOM of the SIU Guaraní page.

The general flow is:

SIU Guaraní
     │
     ▼
Read the study plan
     │
     ▼
Find relevant subjects
     │
     ▼
Extract credit information
     │
     ▼
Filter the required subjects
     │
     ▼
Calculate total free credits
     │
     ▼
Display the result

Instead of asking the user to manually copy information into another calculator, the extension uses the data already present on the page.

Working with the DOM

One of the most interesting parts of the project was figuring out how the information was structured inside SIU Guaraní.

The extension needs to locate the relevant elements, read their content and determine which subjects should be included in the calculation.

This required working with JavaScript DOM APIs and making the extraction logic specific enough to recognize the information I needed without interfering with the rest of the page.

The goal wasn't to modify how SIU Guaraní works.

It was simply to add a small layer of functionality on top of the existing interface.

Keeping the extension simple

Since the extension is designed for students who are already using SIU Guaraní, I wanted the interaction to require as few steps as possible.

The user shouldn't have to:

Open another website.
Copy their subjects.
Enter credits manually.
Calculate the result.
Go back to SIU Guaraní.

Instead, the extension handles those steps automatically.

The result is displayed directly within the existing workflow.

Why I built it

This project started from a very specific problem.

Sometimes the most useful software projects aren't large applications. They can be small tools that remove a repetitive task from someone's daily routine.

For me, this was also an opportunity to apply what I was learning about JavaScript, browser extensions and DOM manipulation to a real problem.

Rather than building another tutorial project, I wanted to create something that I could actually use.

From personal tool to published extension

After getting the extension working for my own use, I decided to publish it so other students could use it as well.

That changed the project from a small local experiment into a real browser extension that had to be packaged, tested and prepared for distribution through the Chrome Web Store.

That process also taught me more about the practical side of browser extension development and publishing.

What I learned

Working on Calculadora SIU CrediUPE helped me understand several concepts that aren't always obvious when learning web development through isolated exercises.

Some of the main things I worked with were:

JavaScript DOM manipulation
Browser extension development
Reading and processing information from an existing web interface
Data filtering and calculation
Injecting UI elements into an existing page
Handling different states of a web application
Testing the extension against the real SIU Guaraní interface
Packaging and publishing a Chrome extension

More importantly, it reinforced something I find important about software development:

A useful project doesn't have to be complicated.

Sometimes a few hundred lines of code can eliminate a repetitive task for an entire group of people.

What's next?

I want to continue improving the extension as the SIU Guaraní interface evolves and based on feedback from students who use it.

I'm also interested in building more small tools that solve specific problems instead of creating software simply for the sake of adding another project to a portfolio.

About me

I'm Ramiro Quintana, a Software Engineer & Full Stack Developer focused on building web applications, browser extensions, SaaS projects and software solutions under quintana.dev.

Calculadora SIU CrediUPE is one of the projects I've built as part of that work.

You can see more about my projects at:
https://quintana.dev.ar/
CrediUPE:
https://quintana.dev.ar/library/siu-upe

And the extension is available through the Chrome Web Store.

How I Built SQUIAM: A Steam-Inspired Interactive Developer Portfolio

ramiro quintana — Wed, 09 Sep 2026 13:42:22 +0000

I'm Ramiro Quintana, a Software Engineer & Full Stack Developer building software projects under quintana.dev.

Most developer portfolios follow the same structure: a short introduction, a list of skills, some projects, and a contact section.

I wanted to try something different.

Instead of building another traditional portfolio, I decided to turn mine into an interactive experience inspired by Steam's interface and the way it organizes games, libraries, profiles, and communities.

That project became SQUIAM.

The idea behind SQUIAM

SQUIAM is an interactive developer portfolio designed around the idea of exploring projects rather than simply scrolling through a page.

The main interface is organized into different sections, including:

A project library
A technical services store
A developer profile
A technology inventory
Community features
Statistics
Real-time chat
Individual project pages

The Steam-inspired design is mostly a starting point. The goal was to take some familiar concepts from the platform and adapt them to a developer portfolio.

The technology stack

SQUIAM is built with React, TypeScript and Vite.

For styling, I use Tailwind CSS together with custom styles to recreate the dark interface and desktop-application feel.

Animations are handled with Motion, mainly for transitions between views and UI elements.

For charts and statistics, I use Recharts.

The application is deployed on Cloudflare Pages and uses serverless functions for backend functionality.

The main stack is:

React
TypeScript
Vite
Tailwind CSS
Motion
Recharts
Cloudflare Pages
Serverless Functions

Designing the interface

One of the most interesting parts of the project was figuring out how to make a portfolio feel like an application.

Instead of having every section visible at once, the interface is built around navigation and discovery.

Projects have their own pages, technologies are presented as part of an inventory, and services are presented through a store-like interface.

This also meant paying more attention to small details such as transitions, navigation states, loading behavior, and responsive layouts.

The project library

The library is one of the main parts of SQUIAM.

Each project can have its own page containing information about what it does, which technologies were used, its current state, and relevant links.

This structure also makes it easier to keep adding new projects without redesigning the entire portfolio every time.

A different approach to services

I also wanted the services section to fit into the same concept.

Instead of presenting a traditional list of services, I designed it as a small software store.

The idea is to make technical services easier to understand while keeping the visual language consistent with the rest of the application.

My work mainly focuses on software development, web applications, browser extensions, SaaS projects and automation.

Why build something this complicated for a portfolio?

A portfolio is already a software project, so I decided to treat it that way.

Rather than only using the portfolio to demonstrate my work, I wanted the portfolio itself to demonstrate how I approach software development.

That meant dealing with the same kinds of problems that appear in larger applications: component architecture, routing, state management, UI consistency, performance, deployment and maintainability.

What I learned

Building SQUIAM has been a useful way to experiment with both frontend development and product design.

Some of the things I've worked with throughout the project include:

Structuring a larger React application
Building reusable UI components
Creating complex interfaces
Working with animations and transitions
Visualizing project data
Connecting frontend features with serverless functions
Deploying applications with Cloudflare Pages
Improving SEO for a JavaScript application
Designing an interface around user interaction rather than a traditional page structure

The biggest lesson for me has been that a portfolio doesn't have to be just a presentation of your work.

It can be one of your projects.

What's next?

SQUIAM is still an evolving project.

As I build new software, I want the portfolio to evolve with it rather than remaining a static collection of projects.

The long-term idea behind quintana.dev is to have a single place where I can publish and showcase the software I build, from experiments and browser extensions to larger applications.

About me

I'm Ramiro Quintana, a Software Engineer & Full Stack Developer focused on building web applications, browser extensions, SaaS projects and software solutions under quintana.dev.

You can explore SQUIAM and my other projects at:

https://quintana.dev.ar/