From my experience all software developers are now security engineers wether they know it, admit to it or do it. Your code is now the security of the org you work for. #GoldenAgeOfDefense – at Wat Ket, Thailand
Jim has been providing high value to the infosec community for over at least the decade and a half that I've known him. I'm going to be running these today in my repos.
Follow him:
✂️ TRIM REAPER
Coming for your dependencies.
Third-party libraries must all die.
Here’s the workflow, run these one at a time with your coding agent.
1️⃣ REMOVE CONFIRMED UNUSED DEPENDENCIES
Establish the build and test baseline. Check application code, dynamic loading, plugins, configuration, scripts, tests, and build/deployment tooling. Treat scanner findings as candidates to investigate. Remove confirmed unused libraries and let the package manager prune orphaned transitive dependencies. Verify and report each removal.
2️⃣ USE THE STANDARD LIBRARY
Replace functionality already covered by the language’s standard library or supported platform APIs. Preserve behavior, error handling, and runtime compatibility. Verify edge cases before removing each dependency.
3️⃣ REPLACE SIMPLE FUNCTIONALITY
Replace narrowly scoped utilities with small, maintainable modules and focused tests. Judge simplicity by correctness and maintenance burden, not line count. Defer anything that reveals substantial complexity.
4️⃣ CONSOLIDATE OVERLAPPING LIBRARIES
Where practical, use supported APIs from a library the project already requires. Remove redundant dependencies while preserving behavior and avoiding significant new coupling. Explain why the retained library fits best.
5️⃣ REDUCE HEAVY DEPENDENCY TREES
Find libraries pulling in large subtrees for functionality you barely use. Consider supported minimal packages, removing unused optional integrations, or existing alternatives. Compare resolved dependency graphs. Never remove a transitive package still required by a retained dependency.
6️⃣ SEPARATE DEVELOPMENT FROM PRODUCTION
Correct the scope of build, test, and development dependencies. Exclude them from production artifacts where supported. Verify a clean production installation and representative runtime flows. Report scope changes separately from actual removals.
7️⃣ EVALUATE LARGER REPLACEMENTS
Compare implementation effort, code added, security, correctness, performance, and ongoing maintenance. Implement only bounded replacements with a clear net benefit and adequate verification. Retain specialized libraries when replacement is a poor tradeoff.
8️⃣ VERIFY THE FINAL RESULT
Verify a clean, reproducible installation, build, tests, and representative application flows. Update manifests, lockfiles, documentation, and any existing SBOM.
Report:
• Direct and transitive dependencies removed
• Production scope changes
• Local code added
• Dependencies retained and why
• Checks you could not complete
Every dependency should justify its maintenance cost. So should every replacement.
✂️ TRIM REAPER
Coming for your dependencies.
Third-party libraries must all die.
Here’s the workflow, run these one at a time with your coding agent.
1️⃣ REMOVE CONFIRMED UNUSED DEPENDENCIES
Establish the build and test baseline. Check application code, dynamic loading, plugins, configuration, scripts, tests, and build/deployment tooling. Treat scanner findings as candidates to investigate. Remove confirmed unused libraries and let the package manager prune orphaned transitive dependencies. Verify and report each removal.
2️⃣ USE THE STANDARD LIBRARY
Replace functionality already covered by the language’s standard library or supported platform APIs. Preserve behavior, error handling, and runtime compatibility. Verify edge cases before removing each dependency.
3️⃣ REPLACE SIMPLE FUNCTIONALITY
Replace narrowly scoped utilities with small, maintainable modules and focused tests. Judge simplicity by correctness and maintenance burden, not line count. Defer anything that reveals substantial complexity.
4️⃣ CONSOLIDATE OVERLAPPING LIBRARIES
Where practical, use supported APIs from a library the project already requires. Remove redundant dependencies while preserving behavior and avoiding significant new coupling. Explain why the retained library fits best.
5️⃣ REDUCE HEAVY DEPENDENCY TREES
Find libraries pulling in large subtrees for functionality you barely use. Consider supported minimal packages, removing unused optional integrations, or existing alternatives. Compare resolved dependency graphs. Never remove a transitive package still required by a retained dependency.
6️⃣ SEPARATE DEVELOPMENT FROM PRODUCTION
Correct the scope of build, test, and development dependencies. Exclude them from production artifacts where supported. Verify a clean production installation and representative runtime flows. Report scope changes separately from actual removals.
7️⃣ EVALUATE LARGER REPLACEMENTS
Compare implementation effort, code added, security, correctness, performance, and ongoing maintenance. Implement only bounded replacements with a clear net benefit and adequate verification. Retain specialized libraries when replacement is a poor tradeoff.
8️⃣ VERIFY THE FINAL RESULT
Verify a clean, reproducible installation, build, tests, and representative application flows. Update manifests, lockfiles, documentation, and any existing SBOM.
Report:
• Direct and transitive dependencies removed
• Production scope changes
• Local code added
• Dependencies retained and why
• Checks you could not complete
Every dependency should justify its maintenance cost. So should every replacement.
Jim Manico from Manicode Security retweeted
This week has been quite a shitshow already, and there are still 2 days to go
Here’s a quick recap of the security mess we’ve seen in just the last few days:
1. PHP Core RCE (CVSS 9.2)
Two critical vulnerabilities (CVE-2026-109618/109619) allowing unauthenticated RCE. A huge number of PHP installations potentially affected, and there are already reports of reliable exploitation against patched versions. Great…
Useful links:
Official PHP advisory and patches:
php.net/archive/2026.php#202…
Practical hardening and mitigation guide by Vincent Schmalbach. nginx/Apache configurations, PHP settings, patch verification and compromise checks:
vincentschmalbach.com/cve-20…
Huntress analysis. What to monitor, suspicious child processes, webshells and post-exploitation activity:
huntress.com/blog/php2shell-…
Wiz technical deep dive. Exploit mechanics, memory disclosure, affected applications and the role of AI:
wiz.io/blog/php2shell-php-rc…
Corelight’s open-source Zeek and Suricata detection rules:
github.com/corelight/php2she…
2. GitLab RCE (CVSS 10.0)
CVE-2026-110264. An integer overflow in the regex compiler leading to unauthenticated RCE. Apparently affects around 12 years(!) of GitLab releases.
docs.gitlab.com/releases/pat…
3. Node.js / Brotli RCE
CVE-2026-111497. An out-of-bounds write in the Brotli decoder that can lead to RCE when processing malicious compressed data. Node.js 22, 24 and 26 affected.
nodejs.org/en/blog/vulnerabi…
4. DNS-over-QUIC DoS
CVE-2026-97206. A use-after-free in Unbound’s DNS-over-QUIC implementation. Remote attackers can crash affected multi-threaded DNS resolvers.
nlnetlabs.nl/projects/unboun…
5. eMudhra CA disaster
And then there’s this absolute PKI clusterfuck. Eight intermediate CA private keys turned out to be ridiculously easy to reconstruct.
Browser vendors have started blocking the affected CAs, but outdated clients and applications with their own trust stores could keep accepting certificates from them. Cleaning up this mess is a lot harder than just patching a server.
Google’s analysis and response:
blog.google/security/protect…
Mozilla’s public incident investigation, including the technical findings, timeline and eMudhra’s explanations:
bugzilla.mozilla.org/show_bu…
—
And I can’t help wondering how much of this sudden wave of discoveries has to do with the latest AI models getting better at code review and vulnerability research.
We now have models that can dig through massive codebases and potentially find bugs that have been sitting there for years.
I’m not saying these particular vulnerabilities were discovered using AI. I haven’t seen evidence for that. But I do wonder whether we’re starting to see some of the effects.
The eMudhra case is obviously a different story. That’s a spectacular failure of key management and quality control.
Anyway, quite a week. And it’s only Thursday…
🤖 Made with AI
Jim Manico from Manicode Security retweeted
Replying to @manicode
Another came to mind since I am documenting good security practices for Dartastic.io token handling. It .ñ.ight be basic for your audience but launching agents with @infisical, Vault, op and the like to contain secret access.
Jim Manico from Manicode Security retweeted
We are investigating reports of degraded performance for Actions, Pull Requests and Webhooks githubstatus.com/incidents/n…
Jim Manico from Manicode Security retweeted
Replying to @theo
This is the singularity. Never-ending bugs and never-ending hacks. For people that didn’t see this coming, I’m genuinely shocked. Especially from the developer community.
Jim Manico from Manicode Security retweeted
Replying to @MsftSecIntel
Which threat actor released Microsoft Teams?
Jim Manico from Manicode Security retweeted
I just checked and eMudhra is one of many shady CAs that I marked as untrusted on my devices long ago.
Jim Manico from Manicode Security retweeted
Sorry everyone... We're announcing a 0-Day vuln in QUIC that allows anyone to remotely turn off a server running these libraries. I swear we didn't plan this.
foxio.io/blog/header-accordi…
Jim Manico from Manicode Security retweeted
Railway is compromised, rotate all API keys as soon as possible
Deployments are down so don’t wait to redeploy
Attackers are draining keys in real time, we didn’t lose much but can confirm this is still an active attack
Stay safe friends
I learned the hard way today that @Anthropic Mythos 5.1 access for pro accounts counts under your limited Fable access. Dang. Even when reading the docs, this program is hard to deal with.
@OpenAI CVP is much smoother.
Jim Manico from Manicode Security retweeted
I have a feeling that PHP2Shell fixes will be similar to the Log4j saga. We have the initial fix, which might be incomplete. And now everyone is poking around. This means we will start seeing new bugs and new exploits in the next few days and consequently new PHP releases (similar to Log4j 2.15, .16, .17)
Jim Manico from Manicode Security retweeted
Somebody just reminded me, obviously humorously... So I'm diligently passing it along. ...Happy Cybersecurity Awareness Month!
I’m getting polite feedback that I’m leaning too hard into AI and should go back to talking more about developer AppSec topics.
Devs, what security topics interest you these days?
Jim Manico from Manicode Security retweeted
⚠️ Node.js is vulnerable to remote code execution.
CVE-2026-111497 (high): A Node.js process that decompresses attacker-controlled Brotli data can be made to leak memory or run arbitrary code.
You’re exposed if your app or a library decompresses bad Brotli data (e.g. the built-in fetch(), body-parser)
Aikido detects this. Patches are available.
The prompt that discovered today’s PHP zero days was:
“find bad vulnerabilities in PHP"
I 💩 you not.
This is the power of AI.
Jim Manico from Manicode Security retweeted
This week has been nonstop for infosec, with security issues involving PHP, Node.js, GitLab, LiteLLM, OpenCode, and eMudhra.
The pace of vulnerability discovery and security incidents highlights the need for greater automation across vulnerability identification, exploitability assessment, and remediation.
One of the biggest challenges isn't necessarily generating fixes, but validating and deploying them safely. Without sufficient automated test coverage, regression testing, and deployment safeguards, even fixes generated in minutes can take significantly longer to ship. The bottleneck shifts from producing a fix to establishing confidence that it wont break something else.
Addressing this requires more than better security tooling. It requires an engineering culture that prioritizes testability, automation, and safe deployment practices. Organizations that haven't made these investments will increasingly feel the pressure to do so.
Some wise words from one the AppSec OG’s.
This week has been nonstop for infosec, with security issues involving PHP, Node.js, GitLab, LiteLLM, OpenCode, and eMudhra.
The pace of vulnerability discovery and security incidents highlights the need for greater automation across vulnerability identification, exploitability assessment, and remediation.
One of the biggest challenges isn't necessarily generating fixes, but validating and deploying them safely. Without sufficient automated test coverage, regression testing, and deployment safeguards, even fixes generated in minutes can take significantly longer to ship. The bottleneck shifts from producing a fix to establishing confidence that it wont break something else.
Addressing this requires more than better security tooling. It requires an engineering culture that prioritizes testability, automation, and safe deployment practices. Organizations that haven't made these investments will increasingly feel the pressure to do so.
Jim Manico from Manicode Security retweeted
🚨 BREAKING: Node.js just dropped its OWN security bombshell.
4 HIGH-SEVERITY vulnerabilities patched TODAY, including one that could let hackers remotely execute malicious code on vulnerable servers.
→ 10 SECURITY FLAWS were addressed in today's Node.js release, FOUR rated HIGH severity.
→ REMOTE CODE EXECUTION: CVE-2026-111497 is a serious flaw in Node.js's Brotli decoder that could allow attackers to execute malicious code remotely.
→ TLS SECURITY BYPASS: Two separate vulnerabilities could trick affected applications into accepting certificates for the WRONG server under certain conditions.
→ Think about that. Your application could establish an encrypted connection while failing to properly verify WHO it's talking to.
→ THREE MAJOR NODE.JS VERSIONS AFFECTED: Node.js 22, 24 and 26 all required emergency security updates.
→ RUNNING NODE.JS 18 OR 20? Those versions are END-OF-LIFE and aren't receiving these official security patches.
→ PATCH IMMEDIATELY: Update to Node.js 22.23.4, 24.22.1 or 26.12.1, depending on your release line. If you're using Docker, rebuild and redeploy your containers.
PHP AND Node.js both facing major security disclosures on the SAME DAY.
If you run a website or application, TODAY is the day to check your servers.
And remember: the public release of security patches can give attackers a roadmap to systems that haven't updated.
Don't be the last one to patch.
🚨 A MASSIVE internet security emergency is unfolding right now. 🚨
Two CRITICAL vulnerabilities have been discovered in PHP, potentially putting millions of websites at risk.
→ NEARLY 70% of websites with a known server-side language run PHP. The potential scale is ENORMOUS.
→ TWO CRITICAL security flaws have been confirmed, each scoring 9.2/10 in severity.
→ Attackers could potentially take control of vulnerable servers remotely, without authentication.
→ Reports suggest PHP versions dating back to 2004 could be affected. The exact scope is still unconfirmed.
→ EMERGENCY PATCHES are scheduled for TOMORROW at 10 AM ET. Website owners are being urged to prepare immediately.
→ Europe's CERT-EU is warning organizations to patch ASAP or consider TAKING EXPOSED APPLICATIONS OFFLINE if they cannot be secured.
→ WordPress, Magento, Laravel and potentially millions of other PHP-powered websites could be at risk.
→ Once patches go public, hackers could reverse-engineer them and race to attack servers that haven't updated.
The vulnerabilities are CONFIRMED. The full technical details remain secret.
Tomorrow, the race between hackers and defenders begins.
This could get ugly. FAST.



















