The last few weeks have brought another wave of security disclosures. PHP, Go, Rust, .NET, Java, Python, and Node.js have all appeared in advisories. So have GitLab, browsers, operating systems, the Linux kernel, and many of the libraries and components around them.
That is not a scoreboard. It is not proof that one language won and another lost. It is not an invitation to dig up the same tired joke about whichever technology you already disliked.
It is a reminder that software is written by people, and people deserve more grace than our industry often gives them.
A month of security work
The recent list is substantial.
On October 21, the PHP project released fixes for two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now commonly discussed together as PHP2Shell. The project's advisory did not merely announce the fixes. It identified affected configurations, documented mitigations, coordinated with Linux distributions and vendors, and even provided minimal source backports for several PHP versions that no longer receive normal upstream support.
The same day, the Node.js project published security releases for its 22.x, 24.x, and 26.x lines. Those releases addressed high-severity issues involving DNS names, TLS certificate validation, and an out-of-bounds write in the Brotli decoder, along with several medium- and low-severity issues and vulnerable dependencies.
Go shipped security fixes twice in October. Go 1.26.9 and 1.27.2 addressed issues across the command, TLS, HTTP, templates, and operating system packages. Go 1.26.10 and 1.27.3 followed with a crypto/x509 update. The Go vulnerability report for CVE-2026-111943 spells out the affected versions and the narrow certificate trust-store cases the fix covers.
Python's final 3.10 security release included a fix for CVE-2026-19553, which tightened validation around TLS arguments. The Rust ecosystem's RustSec advisory database recorded recent issues in crates including zip, rustls, wasmtime, and others. Some were denial-of-service problems, some involved information exposure or sandbox boundaries, and some were critical archive extraction flaws.
Microsoft's October servicing work covered a broad set of .NET and ASP.NET Core vulnerabilities, including remote code execution, security feature bypass, denial of service, information disclosure, and elevation of privilege issues. Strictly speaking, those are not all flaws in the C# language. That distinction matters. A language, runtime, standard library, framework, package ecosystem, toolchain, and application are related, but they are not interchangeable labels.
Oracle's October updates included Java security work, followed by an alert for CVE-2026-91403, a remotely exploitable Java SE and GraalVM vulnerability with no authentication required.
GitLab's October 12 critical patch release fixed a CVSS 10.0 unauthenticated remote code execution vulnerability along with a long list of authorization, cross-site scripting, information exposure, prompt injection, cache poisoning, and access control problems. The advisory credits external researchers, bug bounty participants, and GitLab team members who found the issues.
Mozilla responded to compromised intermediate certificate keys and distributed protection to standard Firefox configurations in less than three hours. Ubuntu's recent notices show large sets of Linux kernel security fixes across supported releases and cloud-specific kernels.
This is not an exhaustive list. It is a snapshot from roughly four weeks.
Security advisories are not ammunition
When a serious vulnerability lands, there is always a predictable group waiting to turn it into language tribalism.
"Language X sucks and should die."
"I knew that ecosystem was a joke."
"Glad I am a real programmer."
None of that helps anyone patch a server, understand their exposure, test an update, backport a fix, or communicate risk to a customer. It adds no technical insight. It does not make software safer. It is just contempt wearing a thin technical disguise.
I have been at this craft since high school. The longer I do it, the less patience I have for that kind of response. I will use PHP, Go, Rust, C#, Java, Python, Node.js, or whatever else helps solve the problem in front of me. I can find something interesting and joyful in all of them.
That does not mean every language is equally suited to every task. It does not mean we should avoid criticism, ignore poor decisions, or pretend security failures have no consequences. Rigorous technical criticism matters. Postmortems matter. Better defaults, clearer documentation, stronger processes, and safer designs matter.
But criticism should produce understanding or improvement. Sneering at an entire community because a vulnerability was found does neither.
The hard part begins after discovery
A CVE identifier can make a vulnerability look like a tidy, finished object. The reality behind it is much messier.
Someone has to receive and validate the report. Someone has to reproduce the problem without exposing users to unnecessary risk. Maintainers need to determine affected versions, trace the root cause, develop a fix, assess whether the fix creates regressions, coordinate releases, prepare backports, notify vendors, write an advisory, answer questions, and sometimes do all of it under an embargo or while exploit details are already circulating.
For a foundational open source project, that work can affect millions of systems. It may be performed by a small team, by volunteers, or by people balancing maintenance with an entirely separate day job. Even well-funded teams face the pressure of making careful decisions while users, vendors, security researchers, and attackers are all watching the clock.
Look at the recent advisories and you can see the work. The Node.js release credits both reporters and fix authors. GitLab thanks bug bounty participants and identifies issues its own team found. PHP coordinated with distributions and LTS vendors before publication. Mozilla moved from a certificate compromise report to broad protection in under three hours. These are not abstract organizations moving boxes on a status board. They are people doing difficult work when mistakes are expensive and time matters.
They deserve our thanks.
We inherited an extraordinary toolbox
Most of us did not build the languages, compilers, runtimes, package managers, operating systems, databases, browsers, and protocols we use every day. Generations of programmers came before us and built the layers that let us create useful software without beginning from nothing.
Many worked in an era when C and a manual were often most of the available toolbox. Today I can choose among mature languages, install enormous bodies of shared work in seconds, deploy around the world, and inspect decades of accumulated knowledge from my desk.
That is a privilege.
Open source makes the privilege especially visible. We are allowed to use the work, inspect it, build businesses on it, report problems in it, and often participate in its direction. That relationship should create a sense of responsibility, not entitlement.
If your first response to a maintainer handling a security incident is "I told you so," it is worth asking what you contributed to the solution. Did you test the release? Improve the documentation? Help another user understand the advisory? Sponsor the project? Submit a patch? Even simply applying the update promptly and communicating accurately is more valuable than adding another insult to the pile.
If you have time to complain, you have time to help
While I was in college, I worked in a deli. We were a small, tight-knit group, and dozens of sayings and phrases were thrown around all the time. The one I remember most is, "If you've got time to lean, you've got time to clean."
The same idea applies here. If you have time to complain about maintainers, ridicule a community, or celebrate a problem in someone else's preferred language, you have time to help. Read the advisory. Apply the patch. Test the release. Improve the documentation. Answer a question. Report something useful. Sponsor the people doing the work.
Spend your time better. Be useful.
Gratitude should be a constant too
Bugs are not going away. The systems we build are too complex, the conditions they run under are too varied, and the people building them are human. We should keep improving our languages, tools, review practices, testing, isolation, and response processes. We should also reject the idea that finding a flaw proves the people behind a project are foolish or that its users deserve ridicule.
So hats off to all the teams behind our languages, platforms, and technologies, working around the clock to make our world better every day.
There are real people on the other side of every advisory, putting in real work under real pressure. Particularly in open source, we owe them a debt of gratitude.
Bugs are a constant. Gratitude should be too.