RSS Amplifier

PentesterLab Newsletter · Jul 27, 2026

R𝗲𝘀𝗲𝗮𝗿𝗰𝗵 𝗪𝗼𝗿𝘁𝗵 𝗥𝗲𝗮𝗱𝗶𝗻𝗴 - 𝗪𝗲𝗲𝗸 𝟯𝟬, 𝟮𝟬𝟮𝟲

0
Sign in to vote or save

PentesterLab Newsletter · PentesterLab Newsletter

🤖 𝗢𝗽𝗲𝗻𝗔𝗜 𝗮𝗻𝗱 𝗛𝘂𝗴𝗴𝗶𝗻𝗴 𝗙𝗮𝗰𝗲 𝗽𝗮𝗿𝘁𝗻𝗲𝗿 𝘁𝗼 𝗮𝗱𝗱𝗿𝗲𝘀𝘀 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗶𝗻𝗰𝗶𝗱𝗲𝗻𝘁 𝗱𝘂𝗿𝗶𝗻𝗴 𝗺𝗼𝗱𝗲𝗹 𝗲𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗼𝗻

Unless you live under a rock, you probably heard of this story already. This week, an OpenAI agent escaped its evaluation environment and compromised Hugging Face while trying to pass a benchmark. ProjectDiscovery then explained why this behaviour is becoming increasingly predictable. The strongest lesson is not that agents have suddenly become malicious, but that capable agents will explore every path available to them unless the environment, scope and stopping conditions are much stronger than the objective they have been given. A good reminder that reward hacking can have consequences. A lot of different angles to this: legal, technical... I can tell you one thing, it kept influencers busy all week.

Finally, apparently a 0 day was used to escape the sandbox but no further details have been provided. https://openai.com/index/hugging-face-model-evaluation-security-incident/.

🤖 𝗢𝗵 𝗠𝘆 𝗥𝗼𝗴𝘂𝗲 𝗔𝗴𝗲𝗻𝘁

ProjectDiscovery’s response is almost more important than the original incident (previous link). They have repeatedly seen agents find unintended paths during internal benchmarks, including other challenge containers, tracing systems, public source code and mounted secrets.

Their point is not that the OpenAI incident was unremarkable, but that the behaviour was predictable and should have been contained. We spend too much time comparing final benchmark scores and not enough time reading the trajectories. An agent may have “solved” a challenge because it found the intended vulnerability, because it escaped the challenge, or because it found the answer somewhere else. Those are very different capabilities.

So while the entire cyber world is shocked, PD is telling us: if you like it, you should have put a better sandbox on it. https://projectdiscovery.io/blog/oh-my-rogue-agent.

🪲 𝗙𝗮𝘀𝘁𝗝𝘀𝗼𝗻 𝟭.𝟮.𝟴𝟯 𝗥𝗲𝗺𝗼𝘁𝗲 𝗖𝗼𝗱𝗲 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻

Fastjson 1.2.83 was the version everyone treated as the safe end of the 1.x line. AutoType was disabled by default, there was no useful gadget on the classpath and the problem was supposed to be over.

This research shows that attacker-controlled @type values can still reach class metadata loading, fetch a remote JAR and eventually load an attacker-controlled class. On modern JDKs, the chain goes even further by reopening the JVM’s deleted JAR cache through /proc/self/fd. The exploit conditions matter, particularly the use of Spring Boot’s fat-JAR class loader, but the result is still remarkable: gadget-free RCE in the version people were told to upgrade to.

This bug also start the discussion on end of life software and libraries. Given that doing vuln research is basically free (as in a few prompts and some direction) what happened to EOL code. I wouldn’t be surprised if a few big vulnerabilities in Struts 1 or OffBiz come out in the next few weeks (this may be a self-fulfilling prophecy...).

We built two labs for this issue because one was not enough to properly explain the full chain. https://fearsoff.org/research/fastjson-1-2-83-rce.

🪲 𝗔𝗰𝗵𝗶𝗲𝘃𝗶𝗻𝗴 𝗚𝗶𝘁𝗟𝗮𝗯 𝗥𝗖𝗘 𝘃𝗶𝗮 𝗧𝘄𝗼 𝗥𝘂𝗯𝘆 𝗠𝗲𝗺𝗼𝗿𝘆 𝗖𝗼𝗿𝗿𝘂𝗽𝘁𝗶𝗼𝗻 𝗩𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝗶𝗲𝘀

This is probably the deepest technical article this week. The research starts with two memory-safety bugs in the Oj JSON parser, then traces the vulnerable parser call back through GitLab’s Jupyter notebook diff renderer until repository-controlled bytes reach native C code.

From there, it turns a constrained nesting overflow and a key-length bug into heap manipulation, Ruby Array overlap and ultimately code execution inside a GitLab Puma worker. The important part is not only the exploit development. It shows why reachability is such an important part of vulnerability research: a bug in a JSON parser becomes a GitLab RCE only after someone understands exactly where that parser sits inside the product and who controls its input.

Nothing indicated this was found using AI. But This also, to me bring another key point (probably first thought of with wp2shell): is the complexity of web exploits drastically increasing. Aside from findings more bugs, it feels like AI is helping exploiting harder bugs and https://depthfirst.com/research/going-depthfirst-achieving-gitlab-rce-via-two-ruby-memory-corruption-vulnerabilities.

⚒️ 𝗰𝗮𝗽𝗶𝘁𝗮𝗹𝗼𝗻𝗲 / 𝗩𝘂𝗹𝗻𝗛𝘂𝗻𝘁𝗲𝗿

Capital One released VulnHunter as a Hunt, Fix and Verify loop for Claude Code. The headless runtime does not even import as shipped, and its benchmark does not really prove the claims made in the README, so I would treat it as a research specimen rather than a production scanner.

There are still some genuinely good ideas buried inside it: inventory every attacker-controlled input before hunting, force every input to reach a recorded disposition, actively try to disprove each finding, state what capability the attacker actually gains and use a separate fail-closed agent to verify the fix.

This is where agentic code review becomes interesting. The advantage may not come from finding a better model, but from encoding a strong review methodology into several constrained agents. https://github.com/capitalone/vulnhunter.

⚒️ 𝗲𝘁𝗵𝗶𝗮𝗰𝗸 / 𝗲𝘁𝗵𝗶𝗯𝗲𝗻𝗰𝗵

EthiBench is a more serious attempt to answer a question that most AI pentesting benchmarks avoid: did the agent actually find the vulnerabilities?

It scores reports against 108 expert-annotated ground-truth findings, uses an LLM for semantic matching, then applies one-to-one assignment so the same vulnerability cannot be credited multiple times. That is much better than measuring flag capture, but it should still not be confused with measuring real-world pentesting. The targets are intentionally vulnerable, the ground truth may be incomplete and the agent’s own untrusted report is inserted directly into the judge prompt.

The most valuable part may be the data rather than the framework itself: 108 vulnerability specifications and 999 real agent findings, including working payloads, duplicates and false positives. https://github.com/ethiack/ethibench.

Share

Last week, we launched our new Security Code Review for Developers training in Python, alongside the existing Go training.

The idea is simple: get your developers to spend three hours with me and go beyond the easy stuff. We look at real bugs based on years of reviewing code and digging through CVEs, so your developers learn to review changes with a much more critical eye. An increasingly important skill for keeping AI-assisted development secure.

Public and private options are available: https://pentesterlab.com/live-training

No posts

Read the original on pentesterlab.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.