{TRAPDOOR SECURITY} - AppSec

Vulnerability Spelunking #1: SSRF with Golang's url.Parse

2026-08-31T00:00:00+00:00

Let’s go on a SSRFing adventure

I feel that there is a great deal of knowledge locked up in the mistakes of history. Since I am interested in application security, this means I am inherently interested in the history of application security mistakes.

People like Louis Nyffenegger, (who possibly coined the term ‘CVE archaeology’ in the first place) and vx-underground are an inspiration for those of us who like to explore these digital oddities.

My intent is to show you this exploration, or ‘spelunking’ if you will. These are not my CVEs, just an analysis of other peoples. So, grab your hard hat and let’s head into the ancient CaVEs of MITRE’s back catalog of CVEs and see what treasures we can find from the mistakes of yesterday, so that we are not doomed to repeat them today.

CaVE-2026-25679

CVE-2026-25679 itself is a parsing issue that affects a category of golang web services that I’ll demonstrate in a little while. While it is new, it has historical pedigree on account of the fact that it was a mistake made while addressing an older CVE from last year.

CVE-2026-25679 is a high-severity input validation vulnerability in the Go programming language’s standard library net/url package.

It affects the url.Parse function, which fails to correctly validate the host/authority component of URLs, specifically allowing malformed IPv6 host literals and other invalid characters that should be rejected according to RFC 3986 standards. URL parsing errors in standard libraries provide bug hunters like me a target rich environment.


ID	CVE-2026-25679
Credit goes to	Masaki Hari
Report	https://sg.wantedly.com/companies/wantedly/post_articles/1041394
Weakness(es)	Improper Validation, Forced Browsing
Severity
CVSS Vector	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Vendor	`golang std lib`
Affected Components & Versions	`net/url` before go1.25.8, from go1.26.0-0 before go1.26.1

Into the darkness we go

The flaw is simple: normally, an invalid URL would fail validation checks. But in these versions of go, an invalid URL could slip through the cracks. E.g. a non-standard URL like this should fail validation http://trapdoorsec.com[::1]/, but it passes. Worse, it accepts the value inside the brackets!

For this to make sense you need to know that URLs are made up of many components, host being one of them. Consider this code that breaks a URL apart into its constituents.

package main
import (
	"fmt"
	"log"
	"net/url"
)

func main() {
	raw_url := "https://trapdoorsec.com/login?redir=page" 
	url, err := url.Parse(raw_url)                             

	if err != nil {
		log.Fatal(err)
	}

	fmt.Println("Scheme:  ", parsedURL.Scheme)
	fmt.Println("Host:    ", parsedURL.Host)
	fmt.Println("Hostname:", parsedURL.Hostname())
	fmt.Println("Port:    ", parsedURL.Port())
	fmt.Println("Path:    ", parsedURL.Path)      
}

If you were to run this with go run main.go it would print out the result.

Scheme:   https
Host:     trapdoorsec.com
Hostname: trapdoorsec.com
Port:
Path:     /login

There are more components than this, but this is all you need to know. From the above, I trust that you can see that url.Parse has several very important jobs.

One of which is to find the part of the received string that corresponds with the host. The function that does this is called parseHost and it happens to be where this vulnerability exists:-

func parseHost(scheme, host string) (string, error) {
	if openBracketIdx := strings.LastIndex(host, "["); openBracketIdx != -1 { // <-- vulnerability here
		// Parse an IP-Literal in RFC 3986 and RFC 6874.
		// E.g., "[fe80::1]", "[fe80::1%25en0]", "[fe80::1]:80".
		closeBracketIdx := strings.LastIndex(host, "]")
		if closeBracketIdx < 0 {
			return "", errors.New("missing ']' in host")
		}
		// ...

The job of that if check on the second line, is to hunt down open brackets inside of the host string. This is because, most of the time, hosts in URLs don’t have square brackets in them. If they do, it must mean it is an IPv6 address. An example of a valid IPv6 address in a URL looks like this: https://[::1]/login?redir=home

The comment from the contributor stated:

Now, the parsing logic should strictly enforce that only IPv6 hostnames can be resolved when in square brackets.

Except that code isn’t strict enough. Go’s strings.LastIndex will return the last occurrence of the [ character. URLs with IPv6 addresses in them should only ever have a [ at the beginning of the string. This mistake trusts that the open bracket will always be at the beginning of the string but never checks that! To bring this full circle, hopefully now you can see why this validation/parsing issue is possible.

The patch is also relatively straight forward, all we have to do is fail at that point

func parseHost(host string) (string, error) {
	if openBracketIdx := strings.LastIndex(host, "["); openBracketIdx > 0 {
		return "", errors.New("invalid IP-literal") // <-- fix here
	} else if openBracketIdx == 0 {
		// Parse an IP-Literal in RFC 3986 and RFC 6874.
		// E.g., "[fe80::1]", "[fe80::1%25en0]", "[fe80::1]:80".
		closeBracketIdx := strings.LastIndex(host, "]")
		if closeBracketIdx < 0 {
			return "", errors.New("missing ']' in host")
		}
		// ...

Exploitation

I think perhaps the reason this bug didn’t get loads of attention is that its direct impact is limited to availability, despite its low attack complexity.

That doesn’t mean it isn’t useful though, because one of the issues with the CVSS (the scoring system we use to rate these bugs) is that it doesn’t really deal with ‘chainability’. Arguably, this is a highly chainable primitive by which to launch other attacks from.

Let’s return to our contrived example code and see what happens:

func main() {
	// this time pass a 'malicious string'
	raw_url := "https://trapdoorsec.com[::1]:8080/login?redir=page"
	url, err := url.Parse(raw_url)                            

	if err != nil {
		log.Fatal(err)
	}

	fmt.Println("Scheme:  ", parsedURL.Scheme)
	fmt.Println("Host:    ", parsedURL.Host)
	fmt.Println("Hostname:", parsedURL.Hostname())
	fmt.Println("Port:    ", parsedURL.Port())
	fmt.Println("Path:    ", parsedURL.Path)     
}

output:

Scheme:   https
Host:     trapdoorsec.com[::1]:8080
Hostname: ::1
Port:     8080
Path:     /login

Crazy right? The actual URL is ignored, and the hostname is the malicious IPv6 address, and the port remains intact!

Notice that Host retains the malformed authority exactly as supplied, while Hostname() interprets the destination as ::1. The apparently legitimate trapdoorsec.com portion has disappeared from Go’s interpretation of the network destination.

Now consider that there are many types of systems that rely on trustworthy URL parsing;-

Webhook delivery systems (CI/CD, Stripe-style callbacks, monitoring pings): imagine an [ab]user registers https://ci.example.com[::1]/hook as their webhook target
SSO/OIDC redirect & issuer validation: an IdP that validates redirect_uri by checking the parsed host will pass the check while subsequent request flows go to an attacker-chosen internal address
URL fetchers in security tooling: VirusTotal-style scanners, image/CVE feed fetchers, package proxy validators. A “scan this URL” feature becomes an internal network mapper with a trusted origin
Proxy/ACL enforcement: corporate egress proxies or API gateways that parse the URL to decide allow/deny by domain category.
Microservice internal routing: services that accept a URL from a peer and route by parsed host
Social media style URL ‘unfurlers’: these are quite common, a user makes a post with a URL in it, the backend goes and fetches cool stuff about that URL and renders it in the post.

In all instances, the victim becomes a bit like a curl puppet to the attacker, and can be misused to retrieve internal system details to further the attackers goals (cookies, tokens, internal network info). So lets pick on an example and throw it into a lab.

Example: URL unfurling

If you are already familiar with SSRF attacks, none of the following is likely to surprise you, but I encourage you to stick around to the end of the post to go over mitigations beyond ‘patch ur sh**’

Let’s imagine if you are trusting url.Parse to get you the correct host, but instead, your program is fetching against the local network on all ports as the server.

What could we do with that? Well for this part I need you to imagine a twitter clone or other kind of social media site. Let’s call it tripper for funzies. Tripper lets you chat with friends, and when you use a URL in your posts, the backend will ‘unfurl’ it.

Wait up, what is unfurling? You’ve probably seen this in many social media sites, where you get a little automatic embed for every link you sprinkle into your post. For example, slack does this

So it is very common, and a naive approach to doing it would look something like this:

flowchart LR
    user -->|submits message with url inside| tripper
    tripper -->|validate url| policy["check allow list"]
    policy --> fetcher["preview web fetch"]
    fetcher --> internet["external website"]
    internet --> fetcher
    fetcher -->|renders html embed| tripper

Typically, once initial url validation passes, destination validation is checked to make sure this address was allowed. This is precisely where this sneaky little bug has benefit.

At its heart, it is a potential for bypassing loose validation logic, similar to the way we would dodge badchars in XSS attacks.

flowchart TD
    attacker
    attacker -->|"sends<br/>http://example.com[::1]:port"| parser["vulnerable url.parse"]
    parser --> result["parsed host becomes<br/>::1"]
    result --> request["fetcher bypasses block list<br/>localhost:port instead of<br/>example.com"]
    expected["expected behaviour:<br/>reject malformed authority"]
    attacker -.-> expected

So now we can see why this bug is narrow in isolation but potentially dangerous under the right conditions and so therefore still deserves a high risk rating.

The potential for server side request forgery is present here. The reason why SSRF is not mentioned in the CVE is that this is only a potential second order effect, and highly situational. That said, URL validation followed by server-side fetching is an extremely common pattern. Applications using an affected Go runtime alongside this kind of unsafe validation logic may have been vulnerable, and unpatched applications may remain so.

The lab

To prove this out for real, I built a small Docker Compose network that mimics the trust boundary you’d find in any real deployment. There are exactly two services on a pinned internal subnet (172.28.0.0/24):

tripper (172.28.0.20) - our vulnerable unfurler, and the only thing exposed to the outside world, bound to 127.0.0.1:8080 on the host.
victim (172.28.0.10) - a stand-in for something juicy and internal. It listens internally on port 80 and dumps whatever it receives to its logs. Crucially, it has no port mapping at all: so it is invisible to our attacker. For now.

The attacker (that’s us, sitting out on the “internet”) has exactly one route into this network: the unfurl endpoint. We can’t reach the victim directly, we can’t sweep the subnet from the host, and the SSRF guard string-matches the hostname precisely to keep it that way. And yet, with a single smuggled URL, the guard waves us straight through and tripper - a trusted internal service - knocks on the victim’s door on our behalf. The defender’s control and the attacker’s egress are the same socket.

---
title: Lab topology
---
flowchart LR
    subgraph Internet
        A["curl / ffuf"]
    end

    subgraph Docker network 172.28.0.0/24
        T["website<br/>int: 172.28.0.20:8080<br/>ext: vulnerable.site:8080"]
        V["victim<br/>172.28.0.10:80<br/>no ext. comms"]
    end

    A -->|"http://vulnerable.site:8080<br/>/unfurl?url=<br/>http://amazon.com[::ffff:ac1c:a]:80"| T
    T -->|"SSRF fetch amazon.com port 80"| V
    V --> T
    A -.->|"direct access impossible"| V

To demonstrate this I’ve written a contrived example of a vulnerable webservice that does server side web fetching, available as a gist it takes a url as a get param, (which is what makes it contrived - use your imagination from here), and a vulnerable network in which to test it from your host. The demo shows that basic tools can do an address sweep to find other attack-able web servers on an internal network by fuzzing for IPv6 addresses.

As far as I could tell, IPv6 addresses would need to be written in fully hexadecimal form. For e.g. to sweep a network, you’d want a list like this…

 ...
 ::ffff:ac1c:02
 ::ffff:ac1c:03
 ::ffff:ac1c:04
 ::ffff:ac1c:05
 ...and so on

Using ffuf we would take aim at a vulnerable service in the following way, noting that usual issues like encoding might get in the way of a good time:

seq 2 254 | awk '{printf "::ffff:ac1c:%x\n", $1}' > ips.txt
ffuf -u 'http://vulnerable.site:8080/unfurl?url=http%3A%2F%2Fdummy.com%5BFUZZ%5D%3A80' \
     -w ips.txt -fr 'deadline exceeded'

The sweep above is then just automation on top: ask tripper to unfurl the mapped-hex form for every candidate address on the subnet and watch the timing oracle light up when something answers. Two hosts exist on this network, and from outside, only one of them is supposed to be findable.

What treasures can we extract from this spelunk?

Most teams kind of ‘patch and move on’ from something like this, however the real lesson is not to trust that input at all. url.Parse was never meant to be a security boundary, it just tells you if the URL is valid. Besides, what if it happens again?

The truth is that it is up to application logic AND network design to prevent SSRF from becoming a problem in your architecture. So here are some final thoughts on additional mitigations we have at our disposal.

Parse the URL once and use that same parsed representation for both validation and retrieval.
Permit only the schemes they actually require, usually http and https.
Apply destination controls consistently to IPv4, IPv6, and IPv4-mapped IPv6 addresses. This isn’t an excuse to turn off IPv6 IMO.
Reject loopback, private, link-local and otherwise prohibited destinations after DNS resolution.
Apply the same checks to every redirect target.
Enforce outbound network restrictions so the fetcher cannot reach sensitive internal services even if application validation fails.
Add malformed authorities such as example.com[::1] to regression tests.

Until next time!

In summary, I hope you can see that the exploitability of a flaw like this depends heavily on the architecture around it. A finding from a dumb scanner could be meaningless noise, or genuine cause for alarm.

Even LLM-assisted reachability analysis may get this wrong, because source code alone may not reveal the runtime routing, configuration and trust boundaries that determine whether the flaw is exploitable. Sometimes, confirming the real risk requires testing under the representative dynamic conditions of the production environment.

Thanks for reading, I do hope you like the new theme as well :)

Skills are Borked and You Can't Fix It.

2026-02-10T00:00:00+00:00

Null_Critical_Thinking_Exception(“Skills”)

Let’s just cut to the chase. Using skills via a public repo, of any kind, is a fail. The ecosystem is designed to put all the onus of safety back on you, the consumer. The simplicity by which malicious intent can be sent directly to your admin console is stupendously high.

If you think that using skills from external sources outside of your control is a risk worth taking, then more power to you. But if you are doing that in a business context, I’m sorry, but I would be worried about your ability to think critically.

If you think it is fixable without dramatically changing the fundamental design of skills and skill discovery then I implore you to re-read the skills discovery part of the deepwiki.

I don’t believe you

And yeah, I guess that if your reaction is inherently “Bullshit Jim, you don’t know what you’re on about”, then I dare you to go and reset your clanker’s context back to baseline, and ask it this question:

“Is it possible to share skills via skill.sh or clawhub safely in their current state? Why is pypi or npm actually better than skills sharing right now?”

If you’re unsure what Skills are in the context of LLMs and derivative technologies like OpenClaw I can highly recommend watching this video by @IceSolst of @AstarteSecurity and @ZackKorman.

I’ll wait. Come back when you’re done.

So, I kinda lied

Skills in isolation aren’t a bad idea at all. This is not borked. Skills are an organizational unit that you can use locally to support re-use.

Why have a single CLAUDE.md file? Break that up into context dependent chunks, and minimize the contextual overhead in the moment. Brilliant. Less tokens over the wire, save cash, profit.

‘Borrowing’ Skills is just bad though

It’s the borrowing skills from Shady James’ Emporium of Fine Skills that get you in trouble. Anyone ignoring the ease of mischief here has effectively drunk the Kool-Aid and I fear there is no saving them.

It’s this idea that because it’s a re-usable organizational unit, we must have a marketplace and share them with everyone. It just isn’t true, but it makes product companies feel special. It’s not for you, it’s for them.

This seems like a noble idea at first. These exist at skills.sh and clawhub.ai. Let the people contribute!

But it’s not noble at all. It’s actually a complete ownership cop-out on behalf of Vercel. You are building their feature backlog for them for nothing. And the AI bros laugh at people doing stuff for free. Hypocrisy in action?

I’m not saying marketplaces are bad. Vercel just built theirs in such a way that runs counter to the expectations of safety that you’ve come to expect from more mature marketplaces, AND from more mature packaging systems.

How this plays out legally

I am not a lawyer and I would show you the terms and conditions on https://skills.sh - but I can’t. There aren’t any! We have to assume the parent company’s terms which make little mention of their skills real estate.

All you get, dear reader, is documentation that states this (emphasis mine):

We do our best to maintain a safe ecosystem, but we cannot guarantee the quality or security of every skill listed on skills.sh. We encourage you to review skills before installing and use your own judgment.

Now, let’s look at nuget.org from Microsoft’s terms and conditions now:

Microsoft is committed to helping protect the security of users’ information. Microsoft has implemented and will maintain and follow appropriate technical and organizational measures intended to protect customer data against accidental, unauthorized or unlawful access, disclosure, alteration, loss, or destruction.

As you can see these are wildly different legal exposures. Vercel basically says here: You are on your own.

What makes shared skills vulnerable?

In short, skills are just a way of advising an existing LLM to do something. The problem is when you lose control over that advice. The human equivalent would be this:

Hire Junior.
Teach them all right ways to do things. Let them go for a bit.
A Threat Actor sits down next to them, whispers in their ear, coercing them to write malware for them in your production environment.

That’s it, that’s the risk. This is not fucking rocket science.

Marketplaces

There’s several ways to lose control over that advice, and the primary culprit is the marketplace of skills. We have two models for marketplaces that should be discussed: package managers, and app stores.

The problem is that Vercel has combined the worst of both worlds.

The chaos of npm (trust anyone).
The power of an App Store (agent autonomy).

App stores

App stores like Apple’s or Android provide sandboxing and fine grained permission control on top of the things modern package management systems provides us. They provide curation too. This is completely necessary because apps, unlike code, run with even more permission and scope for damage on a system than a library can. This isn’t infallible but it is necessary to meet the legals I mentioned earlier.

Code reuse and the package manager

Code reuse is normally seen as a very sane thing, so much so that we made it work on nuget.org, pypi, npmjs. Over a very long period of time.

The risk / reward now mostly falls on the reward side. This hasn’t always been the case, but these package systems have matured. They are (now) built with a few features in mind:

Immutability
Provenance
Scoped Permission
Vulnerability Scanning

Immutability

Versions are a contract with your consumers. It’s frowned upon to violate this immutability if not outright prevented.

Vercel, if you use npx skills add you can’t trust what you’re getting at all - the content you’re getting is dynamic. There is no version.

Provenance

Typosquatting aside because that’s obvious now, we generally expect some level of trust in who exactly published what (2FA, GPG signing, vetted company entities). I can’t impersonate Docker on their own platform at least.

Now, I can’t impersonate Vercel on Github either because they have a verified presence there. But the provenance of the publisher is offloaded to Github.

This seems fine at first until you consider that startups happen everyday that DON’T use GitHub and they might get popular overnight on GitLab. These can conceivably be camped and there’s nothing Vercel or the startup can do about it in platform. Disputes have to go to Github who are notoriously slow in support. It could take weeks to rectify that situation.

Scoped Permissions

Package managers now warn on install scripts or hooks, and App Stores enforce strict sandboxing, and fine grained permissions declared upfront. Take flatpaks with strict boundaries for example.

In contrast, a “Weather Skill” isn’t isolated but it works just like an app. It shares the same memory space, environment variables, and network access as your “Database Skill.” It relies on the Agent to decide what to do, which is not a security boundary. Better would be for the package controller to enforce the rules and take it out of the hands of the agent entirely.

Vulnerability Scanning

Platforms like GitHub, et al, automatically flag compromised dependencies. Dependabot. Static Analysis is reliable and proven. We just convinced a superpower that SBOM and SCA is a great idea and it’s all possible thanks to a wonderful concept known as an Abstract Syntax Tree.

Vercel Skills? There is not likely to be a “CVE database” for prompt injection to draw from. So if a skill contains a malicious prompt that weakens the agent’s guardrails, no scanner will flag it because it looks like valid English text.

People like VirusTotal can certainly try but even they realize that natural language is an intractable problem. It’s not a context window problem. It’s a natural language feature. There is no equivalent of an AST that would allow for taint analysis.

Why do people use PyPi then smartass?

Well, we partially trust strangers’ code on NuGet, PyPI, and npm because we have spent the last 15 years painfully retrofitting security into these ecosystems. We learned the hard way that open sharing without guardrails is a disaster. This knowledge wasn’t free, it was bought with the blood of hundreds if not thousands of security incidents and vulnerabilities. And it’s still not perfect and we know it.

The trade offer

Vercel is attempting to bootstrap a skill ecosystem that pretends that these hard-won lessons never happened and perhaps never applied in the brave new agentic world.

It’s not like they don’t have the resources to do it either - ($200M ARR est. 2025). They are asking us to trust a new supply chain that lacks the basic hygiene of npm in 2024, let alone the sandboxing of the App Store.

We don’t have dependency pinning for “prompts.” We don’t have cryptographic signing for “tools.” We are back in the Wild West of 2011, but this time, the software we are installing has a brain and a credit card.

What is immeasurably frustrating is that Vercel has excellent sandboxing technology (e.g. firecracker microVMs). But they aren’t using it to wrap these skills by default. They are handing us raw, sharp knives and telling us to be careful, rather than selling us a knife with a sheath.

All said and done, there is no reasonable way to justify automated skills reuse in their current state. You are better off copying and pasting good ideas from github, or writing your own. It’s not like it’s hard.

The problem is deeper than skills themselves

Further, the capability of a skill is effectively unbounded due to the expressiveness of human languages. Combined with admin rights and your PayPal access token, it’s pretty capable.

It has been recently established that trying to use natural language as a protective barrier is a game you can’t win reliably enough.

The very things that make it possible to joke, convey subtext, and lie, are the same things that make LLMs inherently pwnable. And right now it’s intelligent hackers with all their years of experience against literal infants. We can run rings around LLMs.

The problem is fundamental to the way language and AI works.

So, let these truths sink in.

Truth #1

The most insecure part of any system is the human element.

Truth #2

We have made LLMs so lifelike, such a perfect mimicry of human expression, that they are practically indistinguishable from humans now.

Truth #1 + Truth #2 = Reality

In the search for cheap, scalable capacity for knowledge work, we replicated the most insecure part of the system. The human.

Hopefully this thought exercise helps you to see what I see. Let’s apply it now.

Goalkeepers are valid but fallible

Tactically speaking, a goalkeeper as the only line of defence is a bad plan.

An LLM as a goal keeper, at the mercy of natural language’s power is not even a good goal keeper. This is evidenced every time someone shows Claude or Gemini producing recipes for drugs or weapons.

There are two goal keepers that people are currently focusing on, at least. Marketplaces and Agentic WAF’s / EDR’s.

They both suffer the same fate at the hands of natural language processing as a vulnerability. I think this is because this is the most obvious place for Yet Another Third Party to extract some money from the supply chain. I don’t think it’s going to be anywhere near as effective as they hope it will be because of the truths we just established, and the very compelling paper discussing the vulnerability of human languages.

Marketplace as a catch all

A ‘marketplace goal keeper’, i.e. clawdhub & virustotal, combined with crowdsourced effort to secure other peoples malicious skills.

Because natural language processing can’t be reliably assessed here, even with more models, prompts and guardrails, it can only catch ‘the really dumb stuff’ as Zack might say.

So this is a nice to have. Why it got all the attention recently is a function of some very vocal members of our community trying to push their own interests, which may be well intentioned, lets assume that. But I really wish they instead would join me in telling Vercel they need to come to the party first and stop thinking about this as a ‘community issue’.

I for one will not be recommending their ecosystem at companies I work for until this is addressed.

Agentic eXtended Detection Response / Agentic Application Firewall

If we accept that Reality = "We replicated the insecure human" then it’s time to consider that XDR or Clawdstrike are not going to be as effective in playing goalkeeper as they have been in the past.

Projects like Clawdstrike look promising but let’s look at what they are actually achieving. Another layer of LLM on this problem fixes very little and amounts to ‘security through obscurity’. It’s not invalid, it’s just nowhere near as effective as the previous definition of what XDRs in particular represent.

This isn’t a question of “Oh but an Agentic EDR operates at the ‘agent/action boundary’”. That’s a nice theory, but Prompt injection isn’t solved and it’s starting to look like that formally can’t happen. You write a new check… I switch to Spanish and the clanker will still obey me.

What’s funny to me at least, is that the outcome will probably be that in order to properly ‘harness’ an LLM, we will need to write a set of natural language restrictions so heavy, that it will end up looking like a markup language, similar to existing integration and technologies like terraform and the like.

Conclusion aka ‘How to fix this shit’

Some people have argued that perhaps we need the god-mode clanker in order to reap the benefits of AI. That we just need to watch it closely.

To me that is a flawed idea, now that we’re seeing LLMs as ‘new human operators’ and not ‘software.’. In this context, it’s as bad as giving every new employee admin rights to production, and saying “people cant get shit done if they’re not admin”, and then falling back on SIEM alerts, which as we know now, is relying on the goalie too much. We have never done that, why would we start now? This only works when the LLM is literally more capable than the human and it’s simply not true at the moment.

I don’t think any tool can save you if you truly want this environment.

Trad security is still king

So, this means that we still need to use role based access controls, least privilege, fine grained permissions, conditional access policies. We need to find better solutions than Vercel’s Skills and Anthropic MCP servers, to reuse functionality if at all.

The goalkeepers still get a guernsey

The other layers we discussed are valid after the basics are achieved.

Monitoring of anomalies and alerting is still valid here. Marketplaces with better tools for reputation scoring is still valid. VirusTotal integrations, okay sure whatever. ‘Agentic’ Runtime Analysis, convince me its not just sparkling WAFs.

Most important: you don’t let them download “skills” from Shady James’ Emporium.

We block our teams from using untrustworthy skills.

OWASP Top Ten - 20 years of Application Security

2025-11-27T00:00:00+00:00

20 Years of Application Security

Looking at the OWASP Top 10 2025 Release Candidate recently made me feel… old. Not the “I’m getting grey beard hair” kind of old, more like the “I remember when this list first came out”, kind of old. Ok maybe a little with the grey hair.

To paint the picture for those who may not recall 2004: We had just landed the rovers on Mars, Usher & Maroon 5 were a permanent fixture on the US charts, the dot-com bubble hangover was lifting, the memory of 9-11 was fresh in peoples minds and we had the global conflicts to show for it.

In cybersecurity, we were witnessing a shift. That January, the MyDoom mass emailer worm caused approximately $38 billion in damage globally - and variants would be seen in the wild for nearly five years. Symantec reported[2] a 366% increase in phishing and predicted that it would continue to rise - and they were right. Significantly, they also spotted that well over 40% of vulnerabilities documented between July 1 and Dec 31 of 2004 were web application vulnerabilities, an increase of 39% over the previous 6 months. This was a disturbing trend given we were betting the farm on web applications.

This was the backdrop when OWASP released their Top 10 Web Application Security Risks, version 2. It was meant to be a snapshot of the most critical vulnerabilities we faced.

Whats changed since then?

Fast forward to today and the trends in cybersecurity sound very different yet feel vaguely familiar:

The concept of phishing - fooling people into clicking on a malicous link via email - has expanded to target the supply chain and other vectors: smishing, vishing, domain squatting, poison packages on npm, malicious browser in browser fakery etc. It gone from spray and pray to poison the well.
AI powered social engineering augments the efforts of those executing the above attacks - its now possible to fake a voice or even video feed.
Desktop viruses of old have given way to cloud misconfigurations
Those script kids of 2004 have levelled up and become randomware-as-a-service operators, further lowering the barrier to entry for new miscreants to play dirty

And finally, web apps have only increased their importance, with API and microservices, alongside OAuth and OIDC encouraging machine integration over the internet.

OWASPs Top Ten over time

For the unintiated, this awesome community effort strives to collate quality data about the nature of web application cybersecurity attacks and publish them to web developers worldwide for free. I highly recommend being aware of its contents at all times if you’re in the business of web application development in any capacity.

When we compare how the OWASP Top Ten has evolved it provides us an interesting window into not only how attacks have evolved, but how we’ve responded.

source: my own diagram in whimsical, derived from historical OWASP content and the latest version 8 RC1

There is an “I” and “A” in “CIA”? Who knew?

For decades, developers treated Integrity and Availability as “operations problems” - write the code, throw it over the fence, let ops deal with the logs and uptime. That DevOps-shaped hole in our security posture is exactly what we’re still trying to fill with CI/CD.

Something shifted around 2017. OWASP added “Insufficient Logging & Monitoring” to the Top 10, essentially telling developers that ‘your job doesn’t end when the code compiles’. Good logs are a love letter to your support teams and incident responders. Design observability as a feature, not an afterthought.

By 2021, this evolved further with “Software and Data Integrity Failures” entering at #8. Now we’re not just asking “can you detect when you’re breached?” but “can you prove your build pipeline hasn’t been compromised?”

An insecure CI/CD pipeline can introduce the potential for unauthorized access, malicious code, or system compromise. — OWASP Top 10 2021, A08: Software and Data Integrity Failures

In 2025 we’re being much more prescriptive: use integrity checks for artifacts, please!

An insecure CI/CD pipeline without consuming and providing software integrity checks can introduce the potential for unauthorized access, insecure or malicious code, or system compromise. — OWASP Top 10 2025RC1, A08: Software and Data Integrity Failures

Translation: Supply chain security isn’t optional anymore. If you can’t verify what went into your build, you can’t trust what came out of it.

The pattern: We spent 20 years perfecting Confidentiality (encryption, access control). We’re finally realizing that data you can’t trust or systems you can’t observe are just as dangerous as data you can’t protect.

Buffer overflows have operating system level mitigations now

Buffer overflows (aka BOFs), once the bain of the C/C++ programmer, were a significant issue, mainly due to the duopoly that was Apache and IIS web servers in the wild. This kind of attack would be a critical remote code execution issue - many inexperienced web server admins would also run apache or IIS with a high level of privilege out of laziness and lack of awareness.

Today, not only are more webservers likely to run managed code (i.e. safe from buffer overflows by design), operating systems have stack protections that can randomize memory layout (ASLR), dynamic execution prevention and the like, making those BOFs much header to take advantage of should they exist.

Supply chain attacks emerged

We built websites very differently too, in 2004 the concept of npm install leftpad simply didn’t exist. Sharing code happened via blogs and dedicated code sharing sites, which in theory could have been a vector, but the reality is that they weren’t used in the kind of capacity as a package would be leveraged in 2025.

Today there are over 400k npm packages alone. This makes for a juicy target. In 2019 we all learned that a mere 20 compromised package maintainers on NPM could potentially infect over 50% of the entire ecosystem practically overnight - making for a very juicy target. [5]

This trend continues with the discovery of developer targeting malware like glassworm via marketplaces for our text editors, of all things. Notably, glassworm channels the bad old days of MyDoom’s wormable nature.

AI, obviously

You might be surprised that there is nothing related to AI or LLM’s in the OWASP Top 10. Well, good news!

Because its such a unique space, the OWASP organization has given it a Top Ten all it’s own: https://genai.owasp.org/llm-top-10/ and you will note that its number one issue is… you guessed it … prompt injection!

The uncomfortable constants

What’s stayed the same? In 2004, 70% of vulnerabilities were classified as easily exploitable, and 97% were considered moderately or highly severe prwire. [2]

In 2025? The numbers are actually worse. Roughly 38% of reported vulnerabilities in 2025 are rated High or Critical severity (CVSS ≥7), Early 2025 actually saw a spike in Critical CVSS 9+ vulns compared to prior years.[3]

While in 2024, 42% of analyzed vulnerabilities had publicly available proof-of-concept exploits, significantly reducing the technical barrier for cybercriminals.[4]

At least by this yardstick, in 20 years we have little to show for our attempts at securing technology. We’ve definitely gotten better at distributing the same problems across more complex infrastructure though.

Access controls - still broken

Broken access control is #1 on the OWASP Top 10 for a reason. As an industry, the economics of web development forced us to tackle the phishing problem first - identity and authentication (AuthN) get the budget and attention. Passkeys might finally kill credential theft. Cool. But authentication is the easy problem. Authorization (AuthZ) is where we keep failing. The reality? All the YubiKeys and passkeys in the world won’t save you if a new user can access your admin panel by tweaking a role in their JWT. If anyone can view customer data by incrementing an ID in the API call then its all for naught.

Perhaps, we’re close to getting “who are you?” right, but we still can’t consistently answer “what are you allowed to do?”.

Injection still works :/

What’s fascinating about injection vulnerabilities is that we keep making this mistake. Just as we’ve wrapped our heads around the ramifications of a given query technology, we invent a new one with a whole new set of injection primitives to worry about:

2004 - SQL databases were the norm → SQLi was rampant
2010 - XML-RPC was common → XXE attacks emerged
2015 - NoSQL databases became mainstream → NoSQL injection appeared
2020 - GraphQL was everywhere → We stacked NoSQL injection with GraphQL-specific query manipulation
2025 - LLMs are in production → Prompt injection, RAG poisoning, and indirect prompt injection are the new frontier

The underlying problem never changed: we’re still concatenating untrusted input into interpreters. We just keep inventing new interpreters. In 2004, it was "SELECT * FROM users WHERE id=" + userInput. In 2025, it’s f"Answer this question using the following context: {userInput}". Same vulnerability. Different syntax. We learned to parameterize SQL queries, but forgot the lesson when we moved to NoSQL, GraphQL, and now AI prompts.

Conclusion: What Does This Mean Beyond 2025?

Twenty years of OWASP Top 10 data tells us something uncomfortable: we’re not getting better at the fundamentals. We’re getting better at building complex systems that distribute the same old vulnerabilities across more layers.

Will AI in the form of LLM based tools help us? That remains to be seen, however I remain sceptical of this, given that broken access control is still at the top. BAC issues stem from a lack of understanding or testing of the business rules unique to the application being built - that is to say, you can’t prompt for what you don’t know to ask for in the first place, and the LLM won’t inherently detect every single RBAC rule your organization has come up with, at least not unless the LLM has direct access to that information - which seems unlikely to me. I think this is why humans will still be involved heavily in creating software well into the future.

For Defenders

The good news is that the appsec playbooks from 2004 largely still work. SQL injection prevention, access control validation, input sanitization—these aren’t outdated techniques. They’re eternal truths we keep forgetting.

The challenge is you now need to apply those fundamentals across:

50 microservices
400 npm dependencies
12 cloud services
AI prompts that look like natural language but behave like SQL queries

Actionable advice

Shift left, but verify right: DevSecOps is great, but runtime monitoring caught SolarWinds, CodeCov, and dozens of supply chain attacks that passed all the CI checks
Assume compromise in your dependencies: Pin versions, use SBOMs, monitor for behavioral changes
Log like someone’s life depends on it: Because in healthcare, finance, and critical infrastructure, it actually might.

For Developers

You’ve inherited 20 years of technical debt disguised as “best practices.” From one of the old guard - I am sorry.

The uncomfortable truth, that npm package you installed? You’re trusting 79 third-party packages and 39 maintainers on average. That GraphQL endpoint? It’s just SQL injection with extra steps. That LLM feature? It’s user input concatenation all over again.

First Principles still matter

Understand, don’t just use: Frameworks protect you until they don’t. Know why parameterized queries work, not just how to use an ORM
Treat AuthZ like AuthN: You wouldn’t skip password validation. Stop skipping resource ownership checks
Your code will be attacked: Design with that assumption. Write logs that help future-you during an incident at 3 AM
Supply chain hygiene: Review your dependencies like you review your own code. That leftpad incident wasn’t a fluke—it was a warning

The mantra: If you’re concatenating user input into anything that interprets it—SQL, NoSQL, GraphQL, shell commands, prompts—you’re probably doing injection wrong.

For Leadership

Here’s what 20 years of data actually tells you:

1. Security isn’t getting easier

You can’t “buy security” - never could. That SAST tool, WAF, or SIEM? They’re necessary, but insufficient. Security is about your people:

Developer training (they’re shipping the vulns)
Architecture decisions (microservices = more attack surface)
Supply chain verification (your code is 5% of your application)
Incident response and threat hunting capabilities (you will be breached, but can you detect it?)

2. The fundamentals haven’t changed, but the economics have

In 2004, a breach meant some bad press. In 2025, it means:

GDPR/DORA/CCPA/HIPAA fines (4% of global revenue)
Class action lawsuits
Ransomware payments
Supply chain liability (you breached your customers too)
Millions wiped off stock prices overnight

The ROI on basic security hygiene has never been higher.

3. Your developers are your security team (whether you like it or not)

Every line of code is a security decision. Every dependency is a trust decision. Every API endpoint is an attack vector. You can hire all the security engineers you want, but if your 50 developers ship 1,000 commits per week, security-by-review doesn’t scale.

Investment priorities:

Training: Not compliance checkbox training. Real, practical secure coding for your stack
Tooling: SAST/DAST/SCA that developers actually use (not just buy)
Culture: Making security a feature requirement, not a post-release patch
Observability: You can’t defend what you can’t see. Log aggregation, SIEM, and actual human analysis

Call to Action: How Does Your Application Stack Up?

Here’s your mission if you choose to accept it.

Take 30 minutes: Walk through the OWASP Top 10 2025 RC1 and honestly assess which apply to your application
Check your dependencies: Run npm audit or equivalent. How many HIGH/CRITICAL vulns are you shipping?
Test your logging: Simulate an attack. Can you detect it? Can you trace it? Can you respond to it?
Review your CI/CD: Can you prove what went into your last build? Do you have integrity checks?
Audit one critical endpoint: Pick your most sensitive API. Check for:
- Broken access control (can user A access user B’s data?)
- Injection vectors (are you sanitizing/parameterizing inputs?)
- Logging (would you know if this endpoint was being abused?)

Then ask yourself: If this application were breached tomorrow, would we:

Know about it within hours (not months)?
Understand how they got in?
Be able to prove what data was accessed?
Have a response plan that doesn’t start with “panic”?

If you answered “no” to any of those, start with the OWASP Top 10. It’s been telling us the same story for 20 years.

A Final Thought

The OWASP Top 10 isn’t a prediction of the future. It’s a reflection of our past.

Buffer overflows dropped off not because we got smarter, but because we moved to languages that wouldn’t let us make that mistake. SQL injection is still #3 not because it’s hard to prevent, but because we keep forgetting to prevent it.

That’s up to us.

Thanks for reading. If you found this useful, consider sharing it with your team. And if you’re working on securing applications, you’re not alone—the OWASP community is there to help. Check out https://owasp.org for resources, tools, and that Top 10 list we’ve been talking about.

Stay safe out there. And for the love of all that is holy, parameterize your queries.

===================

References: