{TRAPDOOR SECURITY} - secure by default

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 :)

The Cost of Complacency: Why 'Secure by Default' Isn't Just Nice to Have.

2024-08-26T00:00:00+00:00

In an era where cyber threats loom larger than ever, being a good global citizen means prioritizing not just functional software but also security by design. Security is an expected function.

Software isn’t difficult, humans are.

You know that overused joke in software circles about there being two hard things? Well, one of those things, ‘naming things’ I feel extends to defining things, because this is where software’s value actually lies: the interpretation and delivery of human requirements, which are notoriously difficult to pinpoint sometimes.

Example time, “Make the car drive autonomously” might look like a requirement to the average person, but in fact it is more of a desirement because it doesn’t adequately express the complexities involved such that two different designs would both meet a standard. Did you mean safely? What does that mean? Should it drive on the left or the right side of the road? Oh, it’s country dependent? How will it know, oh, so it needs GPS. Right. What if that fails? *

So we need to understand, that to a product team, saying ‘secure by default plzkthxbai’ is really just a way of being annoying and 100% non-constructive. They know it’s a good idea, just… how?

Why do we even care about secure by default?

OK so, I’ll admit, if somebody says to me that secure by default is not a priority, I get a bit hot-blooded. It makes me want to lean into the fact that I’m a grumpy old man and tell the war stories again.

Reality is though, people clutch their pearls every time something awful happens, but nothing materially changes the status quo.

The Morris Worm incident

In 1988, an enterprising young student named Robert created what he thought was a harmless experiment, presumably, to measure the size of … um… the Internet. (Morris is reported to have stated that he only did it to see if it could be done.)

However, his program relied on a default password and a buffer overflow vulnerability in the canonical email service of the day: sendmail - a Unix program.

He designed a self replication component to his program, and before he could say ‘off by one error’ he had infected around 10% of the Internets servers at the time (approx 6000 machines), and caused millions of dollars damage in lost productivity.

This moment was pretty significant, in that it hadn’t really happened on this scale before, but it also perfectly demonstrates why having insecure defaults opens us up to one of the nastiest types of malware: the worm - a self replicating program capable of spreading itself without user interactions.

The Code Red Incident

Another example: we used to be OK with Windows Server 2003 leaving port 445 (SMB protocol) open on install. Code Red made especially good use of this fact - some of you will remember - their cyberattack of 2001 which targeted another default configuration in IIS (open port 80). 24 hours, 350000 servers brought to their knees, billions in lost productivity. (Moore, Shannon, Klaffy 2002)

You can see where the product design decisions come from: make the Internet easy to play with! Make networking easy! Minimize the clicks a server admin needs to take in order to ‘get online’! All laudable, money making ideas. Entirely insecure.

Alas, these weren’t entirely addressed until 5 years later, in Windows Server 2008 as Microsoft now had the ‘very insecure’ label that they probably wanted to shake.

Fast forward to 2024: IPv6 has the same problem

It has recently been revealed that IPv6 had a vulnerability, causing concern among IT professionals.

The reason for this is that it also is ‘wormable’. Why is that? How can a bug in an internet protocol do that, when there was no default password?

In this case, the issue is that many devices and indeed operating systems, enable IPv6 by default, even though they don’t strictly need it. Combine that fact with the remote code execution vulnerability in IPv6, and suddenly, we have a worm.

Conclusion: Water is wet and investors don’t care.

All this did not ruin Microsoft, Unix still exists today, SMB is still a protocol that is used. So, none of the impacts where so bad that humanity cancelled them from all relevance. This tale is repeated in the Solarwinds breach and Crowdstrike outages of late. Go have a look at Crowdstrike share price, I dare you.

Now look at Equifax.

It would seem that lost productivity makes for a good (bad?) news story, but as a society, I don’t think we value it as much as journalists would have you believe. Surely, we move to fix things all-proper-like when people die though, right?

Right?

Stuxnet, WannaCry, Ransomware in general, heck arguably, even the old Therac-25 Radiation Therapy Machine of the 1980s were all situations where human lives could have been, if not were, affected because of insecure by design or other design flaws we would consider to be security adjacent.

So no, fact is, when it all comes down to the cold hard math of making said crusts, people (not just ‘big evil companies’ I might add), put their earning potential ahead of all else.

This is extremely short-sighted

At the moment we enjoy relatively cheap technology, maybe a few more ads than I’d like, but for those with enough means to purchase a device, much of the software you need to make your life easier is near enough to free.

The thing that does change though, is the rate at which we embed technology into the critical parts of our lives. This is a given.

In order to protect lives, we are now looking at the alternative solution to businesses regulating themselves. Of course, I mean governments doing the regulation bit. And this will make everything more expensive.

Where businesses fail to act, governments step in

Remember when cars didn’t have seat belts? OK, so I don’t either, but that was a big issue in the 60s, people were dying enough that Ralph Nader wrote a book about it.

That led to loads of litigation and then government regulation, and finally, a massive increase in safety.

It also added well over 10% to the price of a car, depending on what sources you refer to. Could businesses have avoided this? Could cars have been cheaper and safer?

So given the above, in my opinion, tech companies will have their ‘Ralph Nader’ moment in the future, and until then, things aren’t likely to change.

The US Government is actually doing something meaningful to prevent the repeat of history

Enter the CISA recommendations of 2023, which is the first attempt at a government (that I’m aware of, at least), that tries to properly define ‘secure by design’.

The subtext is often missed though. CISA is trying to give us all a massive hint: “start doing these things before we force you to do them.” They know that the lawsuits are coming, governments are even enabling them, as one of the biggest customers of technology, this makes perfect sense.

What if we adopted the CISA recommendations then…

Alright, so you want to be a good global citizen and make software that is secure by design? First up. Thank you, for trying to play the long game, and make software cheaper for everyone by raising the bar and customers expectations!

There is no single solution to end the persistent threat of malicious cyber actors exploiting technology vulnerabilities, and products that are “secure by design” will continue to suffer vulnerabilities; however, a large set of vulnerabilities are due to a relatively small subset of root causes

-Secure by Design: Principles and Approaches to Secure By Design Software, CISA, 2023

In this document two definitions now exist that you can hang your hat on as a product designer, or software engineer.

Secure by design

“Secure by design” means that technology products are built in a way that reasonably protects against malicious cyber actors successfully gaining access to devices, data, and connected infrastructure Software manufacturers should perform a risk assessment to identify and enumerate prevalent cyber threats to critical systems, and then include protections in product blueprints that account for the evolving cyber threat landscape.

Secure by default

“Secure by default” means products are resilient against prevalent exploitation techniques out of the box without added charge These products protect against the most prevalent threats and vulnerabilities without end-users having to take additional steps to secure them Secure by default products are designed to make customers acutely aware that when they deviate from safe defaults, they are increasing the likelihood of compromise unless they implement additional compensatory controls Secure by default is a form of secure by design

Security should not be a luxury option, but should be considered a right [that] customers receive without negotiating or paying more.

Honestly, there are so many good reasons to read this paper, just do it.

Summarizing for you though, they do a great job of boiling this down to three core principles that any business owner can apply to their company.

Take ownership of customer security outcomes
Embrace radical transparency and accountability
Build organizational structure and leadership to achieve these goals

For product designers and engineers we go deeper:

Memory safe language use
Lean on hardware that can use fine-grained memory protection
Acquire and maintain secure software components (yes, this means libraries and middleware)
Lean on web frameworks that properly escape inputs
Use parameterized database queries to avoid injection flaws
Use static and dynamic application security testing tools to assist in error detection
Code review should be a thing you do (i.e. QA)
Provide an SBoM
Establish Vulnerability Disclosure programs
Include root cause or CWE references in CVE reports
Design infrastructure such that the compromise of a single security control does not result in total system compromise.
Meet a baseline of Cybersecurity Performance Goals, which are too numerous to mention in this article, use this link as reference instead.

At what cost?

Every time we have a ‘black swan’ event your customers governments are more likely to react with legislation. If you simply build like this today, you amortize that cost over the course of years, not months. A recent estimate puts this cost in the US at “$300 billion annually, only $53 billion less than firms spend on corporate income taxes.” (T)

Your customers and investors probably won’t notice immediately, but when your competitors jack their prices up, you’ll be smugly pointing to all the good work you did over the past few years and reaping the churn.

History shows us that without proactive measures from within, industries often face stringent external regulations. By adopting CISA’s 2023 recommendations now, technology companies can not only avert crises but also pave the way for a safer digital future. It’s not just about avoiding penalties—it’s about leading the charge towards a more secure world. What steps will you take to ensure your products are secure by design?

Final thought, consider how much government regulation costs other industries and start factoring it into your strategic thinking, today. Because the warning shots have been fired.

*- Complete aside: In the author’s opinion, this is why, time and time again, ‘no code’ solutions fail to live up to expectations (because they produce an unmaintainable mess that defies to be safely modified) and, why the armies of new wave AI-only ‘programmers’ aren’t taking all the jobs in IT (because programming isn’t the only skill we’re hiring for here).

References

https://www.abc.net.au/news/2017-05-14/ransomware-cyberattack-threat-lingers-as-people-return-to-work/8525554
https://www.wired.com/2002/01/find-the-cost-of-virus-freedom/
Code-red: case study on the spread and victims of an internet worm, D. Moore, C. Shannon, K. Claffy, https://dl.acm.org/doi/10.1145/637201.637244
The Internet Worm Program: An Analysis, Eugene H. Spafford, 1988 https://spaf.cerias.purdue.edu/tech-reps/823.pdf
https://x.com/paulg/status/1323246618326507524
https://www.theregister.com/2024/08/14/august_patch_tuesday_ipv6/
https://www.cisa.gov/resources-tools/resources/secure-by-design
https://www.sec.gov/newsroom/press-releases/2023-139
https://www.theregreview.org/2024/02/28/hoguet-estimating-the-impact-of-regulation-on-business/
https://obamawhitehouse.archives.gov/omb/inforeg_intro