
i make computer do bad 🧙 security researcher 📺 1M+ youtube prev: fuzzers & hypervisors @microsoft Business: [email protected]
Washington D.C.
Joined July 2021
- Tweets4K
- Following1.6K
- Followers58.1K
- Likes16.5K
Low Level retweeted
Planned to drop a macOS 0day at OffensiveCon 2026 in Berlin 5 months ago. Submitted it to Apple 3 years ago, and Apple confirmed the vulnerability but closed the report. it's a universal method to bypass many security protections on macOS and you can fully bypass TCC and gain other privileged access as you want, easilly weaponized.
Although I mentioned the impact multiple times, there were no updates for the next 2 years until my presentation was accepted by OffensiveCon26 Berlin. Apple asked me to hold off on disclosure and not disclose the vulnerability at OffensiveCon26 Berlin, saying a patch would be released in macOS 27 in Fall 2026. They also mentioned "bounty" multiple times.
Honestly, I did have some complaints because their workflow was really bad. No updates at all until disclosure was about to happen. But as long as they decided to patch it, I was willing to wait, even without a bug bounty, for user safety. If Apple wasn't going to release a patch for 3 years, I'd disclose the vulnerability so EDR vendors could protect users too.
But in September, when the vulnerability was patched, there was no cve, no credit, and no bounty.
I really don't get why apple chose to handle it in such a dishonest and underhanded way, a cheat. Even if they had never mentioned a bounty, I still would have held off on disclosure because they were going to publish a security bulletin.
this is a huge disappointment in my experience with the Apple Security Bounty program. never thought I'd encounter something like this. As i said on my blog a few years ago, my experience with ASB had been positive. that's why I was willing to wait for the patch even without a bounty, but not to be cheated like this
ctf in 2014: run this program in a debugger
ctf in 2026: become a threat actor and exploit this 0day with no public poc
Congrats to @killa who solved stealmybitcoin.com hours ago but I screwed up which key went on the server (the flag was a root wallet WIF instead of the branch WIF).
Check out their awesome writeup here: github.com/KillaBoi/StealMyB…
this isn’t a dunk by the way great work @killa . It’s just funny how far things like this have progressed
🤪 TELL ME YOUR WACKY HACKER NAME
First Name: your IP Address
Middle Name: username
Last Name: that WACKY private key (PEM format)
Real talk I know he’s joking but I hope everyone’s doing okay.
This industry is rough sometimes.
Make sure you go and literally touch grass, look at the sun (not directly you know what I mean)
I think we've discovered another critical vulnerability:
CVE-2026-BURNOUT: AppSec Professional Exhaustion
Severity: Critical (CVSS 10.0)
Description: A vulnerability affecting security professionals exposed to a continuous stream of critical RCEs, zero-days, emergency patches, and Friday afternoon disclosures.
Impact: Sleep deprivation, excessive caffeine consumption, and an inability to enjoy weekends.
Attack vector: Reading security advisories.
Affected versions: All AppSec professionals, regardless of experience.
Mitigation: No known patch. Air-gapping may delay the inevitable. Total system collapse remains a possibility. 🔥
Low Level retweeted
A trusted contact who has a working exploit tells me reliable exploitation is still possible against PHP 8.2.35 and 8.5.12, despite the security updates.
According to their testing, setting
session.upload_progress.enabled = Off
blocks that exploit path.
I haven’t reproduced this myself. Whether this is an incomplete fix for the disclosed CVEs or a separate issue still needs clarification.
Leaving this here, PHP 8.5.12 security patch is incomplete. ( needs further validation )
Readers added context they thought people might want to know
Unvalidated AI output (author admits in replies: omp with glm5.3 + ds4), not a lab result. Its screenshot says both CVEs are fixed; the 'surviving paths' need unserialize() of attacker data or an app LFI. Patch per php.net: php.net/archive/2026.p…
Replying to @Railway
i'm sure you're all better than me at this but just some of what we've seen if it helps - they're not going to stop. it's going to get increasingly sophisticated and they're going to go after every surface of your system and all of your employees
any old projects you've long forgotten about will be found and used against you
the only reason we're surviving is because we have agents going 24/7. we're still barely sleeping
good luck, sorry you're dealing with this, but really it's a collective problem we're all facing together
BRRRRRROTHER
Node.js Security Advisory: a high-severity RCE flaw in Node's Brotli decoder affects Node.js 22, 24, and 26.
Vercel WAF rules are live for every project and block known exploit patterns.
vercel.com/kb/bulletin/node-…
Low Level retweeted
Node.js Security Advisory: a high-severity RCE flaw in Node's Brotli decoder affects Node.js 22, 24, and 26.
Vercel WAF rules are live for every project and block known exploit patterns.
vercel.com/kb/bulletin/node-…
friend asks you to drive him to the airport on the same day your dog died
We are investigating reports of degraded performance for Actions, Pull Requests and Webhooks githubstatus.com/incidents/n…
Low Level retweeted
Critical PHP vulnerabilities to be disclosed tomorrow: php.net/archive/2026.php.
We're working directly with the PHP Foundation to get patched PHP versions into our base images for Laravel Cloud, Forge, and Vapor ASAP.
You may need to redeploy your apps at that time to use these patched versions, but we're also working on the ability to silently patch applications without needing a redeployment.
All customers have been emailed and we will be providing further updates via email as the situation evolves.
Low Level retweeted
Since I heard about this #PHP #RCE last week, I've been preparing a tool for everyone who doesn't know what to do right now:
process-watcher shows you every program your PHP processes start, with full command lines, so you can spot suspicious activity
Until a patch is out, isolation (containers) and tight monitoring are your best bet to limit the damage. And I'm sure the LLMs already go "brrrr" and people are trying to reproduce the vulnerability.
From what I've heard, exploitation will probably show up as suspicious sub process spawns. That's exactly what this watches, using eBPF: one static binary for Linux (amd64, arm64), no dependencies, running in a few minutes. It can also kill the ones you name (dry run first), but it's a detection layer, not a patch, and it can't see anything that happens inside PHP without starting a process.
Quick start: github.com/Neo23x0/process-w…
Project: github.com/Neo23x0/process-w…
holy shit this is so bad lol. wormable RCE over the air
























