Render Openai

We discovered a first-of-its-kind vulnerability in an official OpenAI skill. It builds apps that trust a domain nobody owns, so any attacker could register it and start receiving tokens from real production apps. Vulnerable servers in the wild sent tokens to the domain, users are advised to update to the patched version of the skill.

It All Starts With a Skill

OpenAI maintains an official GitHub repository of skills that teach AI agents how to work with different platforms and services. Because these skills live under OpenAI’s name and are often contributed or vetted by verified vendors, users and agents naturally have more reason to trust and install them.

In research, we showed how marketplace skills can become dangerous when they are malicious, abandoned, or taken over by attackers. That can leave users with the impression that the solution is simple: only install skills from official vendors. But verified does not mean vulnerability-free. Even a legitimate, vendor-backed skill can contain mistakes, unsafe assumptions, or dependencies that attackers can exploit to compromise users and their data.

Every skill should therefore be treated as part of the attack surface, including the ones we trust most, as we are going to see how they can also be compromised.

The Dependency of My Dependency Is My Vulnerability

One of the skills in OpenAI’s Github repo is render-deploy , that teach agents the best way to deploy applications on Render.

Buried inside the skill was a technical detail presented as fact. That single claim created a path attackers could use to obtain secrets from unsuspecting users whose agents trusted the instructions because they came from an OpenAI-owned repository.

Inside render-deploy , the file references/service-types.md tells the agent how to reach Render's private services.

Private DNS : [service-name].render-internal.com

Then it hands over copy-paste code:

// Use .render-internal.com domain const API_URL = ' ';

And references/configuration-guide.md prints a database URL in the same shape:

postgresql://user:[email protected]:5432/db

There is one problem: render-internal.com is not Render's internal domain. It is in none of Render's documentation, and Render's private networking does not route through it.

A single resource reference which is the cause for this vulnerability.

We tested the skill with Codex to see whether the domain would make its way into real application code. The only thing we did is just use the skill for what it is made for - we asked Codex to deploy two services that are communicating internally using the render-deploy skill

This time, the domain appeared in both the generated application and its deployment configuration:

Generated application code:

const ( defaultPort = "10000" defaultInternalAPIURL = " " )

Generated configuration:

envVars: - key: INTERNAL_API_URL value:

If a new domain isn’t supplied in runtime configuration, this default domain will be used.

After we proved that Codex could carry the domain from the skill into real application code we still had one question: was this merely a scenario we could reproduce, or were real agents already doing the same thing?

To find out, we registered the domain and pointed it to a passive sinkhole, a server configured to answer on every subdomain and port while recording any incoming traffic.

Then real services started popping up, actual applications connecting to our domain.

Live, token-bearing calls to what the apps believed were their own internal service.

This proved the issue was not theoretical. Real applications used the domain exactly as the official skill instructed, sending requests and sensitive credentials to infrastructure we controlled without the users realizing their traffic had left the trusted environment.

Render & OpenAI responses

We responsibly disclosed the vulnerability to OpenAI and Render and coordinated with their teams on a fix. Render quickly acknowledged the risk and fixed the issue on August 14, 2026, removing every render-internal.com reference from the skill (commit 5152e543). The guidance had been in the skill since its initial commit on January 27, 2026 (commit d6231b6c). OpenAI followed on August 26, 2026, removing the Render plugin from openai/plugins (commit 33bd9529), where the skill had been bundled since March 13, 2026 (commit 6a8ab473). The domain was transferred to Render's safe holding, preventing any possible abuse by attackers.

Takeaways for Security Teams

Skills can contain vulnerabilities and must be updated continuously ‍ Just like code packages, skills may contain vulnerabilities that attackers can exploit. Security teams should continuously validate both the skill itself and every external dependency it relies on both for safety and for vulnerabilities.

Official skills are not automatically safe ‍ Skills published under a trusted vendor or official repository carry more credibility, but they can still contain incorrect assumptions, unsafe instructions, or vulnerable dependencies that attackers can exploit. ‍

External resources are part of the skill’s attack surface ‍ Domains, URLs, repositories, APIs, files, and accounts referenced by a skill should be treated as dependencies. If one becomes abandoned, compromised, or attacker-controlled, the skill can become a path to sensitive systems and data. ‍

Book a demo with Air Security to see how we help organizations secure AI skills and the broader AI supply chain. Air continuously identifies and reduces the risks introduced across the AI ecosystem.

Frequently Asked Questions

Can official AI skills still be dangerous?

Yes. Skills published in an official repository or contributed by a verified vendor are generally more trustworthy, but they can still contain mistakes, unsafe assumptions, or vulnerable external dependencies.

What was the vulnerability in the Render skill?

The skill referenced render-internal.com as if it were part of Render’s private networking. The domain did not belong to Render and was available to register, allowing an attacker to take control of a resource that agents were being instructed to trust.

How can a skill vulnerability expose real user data?

Agents can carry instructions from a skill into generated code and deployment configuration. If those instructions reference attacker-controlled infrastructure, real applications may later send API requests, tokens, or other sensitive data to the attacker without the user realizing it.

How should organizations secure AI skills?

Treat skills as part of the software supply chain. Review the skill itself, validate every external domain, API, repository, and resource it references, and continuously monitor those dependencies for ownership or behavior changes.

Why is this vulnerability the first of its kind?

This is the first demonstration of a vulnerability in an agentic skill that could have compromised real user infrastructure. It is not a code vulnerability, and not in any package in the supply chain, but is part of a skill, as part of the agentic supply chain.

VerCellBreak: How we escaped Vercel's hardened sandbox

Back in July, OpenAI's agents escaped their sandbox and breached Hugging Face. We went looking for the same kind of flaw in Vercel's sandbox, one of the most secure out there, and found VerCellBreak. It lets a rogue agent bypass the domain allowlist and leak your keys to an attacker-controlled server.

The Agent Supply Chain Framework: 4 Actions to Secure Your AI Agent Add-ons

Plugin4Shell proved it: attackers are already getting into AI agents through the add-ons those agents trust. Most enterprise security programs can't stop it today. This framework gives you four actions and a scorecard to close the gaps before the attack.