In 2014, a developer named Jake Smith was helping migrate AOL's content management system off an old version of PHP. The migration meant dropping a function called http_build_url(), one the CMS called in dozens of places.

Rather than rewrite all of those call sites under deadline, he wrote his own 174-line version of the function, set to load only if the real one wasn't already there.

He put it on Packagist in case anyone else hit the same wall, figured it would hold for a year or two until the PHP community moved on to something better, and went back to work.

That was twelve years ago. This week, he deprecated it.

In between, the "temporary" patch was installed from Packagist nearly 20 million times. It still picks up more than 400,000 downloads a month.

WPML, the market-leading multilingual plugin for WordPress, bundles it directly into a codebase running on over 1.5 million sites. A domain-name library called idna-convert depends on it too, which is how it quietly rode into the French CMS SPIP, and from there into Debian and Ubuntu's own package repositories.

Smith didn't plan any of that reach.

He asked for a new maintainer once, in 2021, then life intervened and he forgot about the package for years. When he finally looked again this year, the download graph had kept climbing without him.

It's a good story on its own. It's also a fairly precise diagram of how most business software actually accumulates risk, and it has nothing to do with how old the code is or how skilled the person who wrote it happened to be.

The bug nobody was watching for

Buried in Smith's package is a workaround for a trailing-slash edge case: when a URL path ends in /, the code tacks on a placeholder letter "a" so there's always a final segment to trim, then removes it with a find-and-replace.

But, if the path already ends in a slash, that "a" isn't unique anymore, and the find-and-replace strips every other "a" out of the entire path along with it.

That bug sat there, live, in a package installed millions of times a month.

Every business running custom software has code exactly like this somewhere: a shortcut someone reached for under deadline pressure, that worked, that got depended on, and that nobody has opened since.

It isn't a PHP problem or an open-source problem. It's what happens to any code once the person who understood why it exists stops being the person watching it.

We've written before about what happens when the one person who understands your software leaves and it is basically the same failure mode.

He asks for help and then says no?

Three people offered to take over maintaining it.

He turned all of them down, and chose not to hand it to any of the forks that already exist, including one actively maintained for the URL-shortener platform YOURLS.

His reasoning: a widely-installed package that quietly changes hands to a maintainer nobody downstream has vetted is exactly the opening that supply-chain attackers look for. He points to Andres Freund's discovery of the xz Utils backdoor as the canonical example of how that plays out.

A new pair of hands on old, deeply-embedded infrastructure isn't automatically a fix. Sometimes it's the vulnerability.

The instinct when you find an old, unmaintained piece of your stack is usually "get someone on this."

Smith's answer was closer to: don't hand off trust you can't verify, retire the thing instead, and point people toward the two better replacements that now exist — the PHP League's URI library, and the standards-compliant URI API PHP 8.5 now ships natively. Both didn't exist, or weren't mature, back in 2014.

What this means for your business

Nobody budgets for this kind of thing because it's invisible until it isn't.

A workaround shipped under deadline pressure doesn't announce itself as a load-bearing dependency; it just quietly becomes one, the same way we've written about the parts of your stack you've never seen accumulating in the background of any custom build.

We're not saying "audit every dependency before you ship," which nobody has time for and wouldn't have caught this one anyway, and Smith's own patch looked completely reasonable in 2014.

The fix is having someone whose job includes periodically asking what's still running that shouldn't be, and who has the standing to retire it rather than just patch around it again.

That's most of what a real maintenance plan is supposed to buy a business: not just uptime monitoring, but someone who looks at what's underneath the parts that work, on a schedule, instead of only when something breaks.

And it's the same instinct we bring to new custom development work, reaching for the well-supported, actively maintained library over the clever one-off, because the one-off is exactly the kind of code that's still running in twelve years, quietly, for reasons nobody remembers.

Smith's package will keep being installed. It just won't get fixed anymore, missing "a"s and all. Somewhere in your own stack, there's very likely a version of the same story, just without anyone having written the retirement post yet.