Naughty ASN of the day: AS*

Fuck it, just block it all. Go outside. Keep walking. Further. Into the woods. Become one with nature. Permanently. And relax. Finally.

Hey, has IFIN been valuable to you this week? We sure would appreciate some support of the mission. We're a registered nonprofit and rely on community support to keep the lights on!

https://ifin-intel.org/support

#ThreaIntelIsMutualAid

@mttaggart so, there is a real reason to be very concerned here.

a metric ton of vibed apps are on node and all aren't in "vercel" (et al.) that will get auto-patched.

alot of those apps are not going to see an update either at all or for a while, and it's unlikely the vibes pinned `@latest` for versions.

a cpl more of these type of vulns and it's gonna be wild out there.

Node and Python were feeling left out, so here's an RCE that needs attention. The Node issue, referred to as #Node2Shell, appears fairly exploitable. Check your Node versions and update. Check for affected Python packages as well.

https://ifin.network/t/cve-2026-111497-brotli-out-of-bounds-write-impacts-node-python/929

#ThreatIntel

Really loving how everyone with an AI agent is a cybersecurity expert now

The Phermi Paradox

If #PHP2Shell is so gnarly and so many systems are vulnerable, why hasn't half the internet fallen over?

Couple possibilities:

1. The exploit is still non-trivial and building the full attack chain is taking some time.

This is at least partially true. I've yet to see a fully reliable proof-of-concept exploit that addresses all versions of PHP. Calif and Wiz showed exploit videos against targets. They didn't show what pregaming they did to prepare the exploit for those specific targets. So far, it seems like some prior work is necessary to get proper offsets, heap layouts, and payload shapes to exploit properly.

And that's assuming the mod_php SAPI, which responds differently to this than PHP-FPM.

2. Patching was aggressive and major targets had time to get in front of this.

For larger orgs, I believe this is accurate. The message was clear enough, and there was time enough to get any org with a half-awake IT team to circle the wagons. Patching isn't done, surely, but I think the most enticing targets for notable attacks probably moved quickly.

It's also worth noting that status dashboards like this are mostly a fairy tale. Look at the bottom for some whopper disclaimers. OS backports to versions other than PHP's official patched versions will muddy the picture, as will the 50% of PHP services that don't report versions. I'm not saying most of the internet is patched; I'm just saying we can't rely on these metrics as truth.

But let's not ignore the alternative:

3: The exploited won't know it's happening and won't report it.

This is hardly a new phenomenon PHP sites have been exploited for years without anyone noticing (see: Slot Gacor). Exploitation won't look like the internet blinking off. It'll look like a bunch of gambling pages and piracy hosted on school and municipal government websites. Such attacks can lie quietly on PHP sites for years before anyone bothers to look.

Android Auto without Google Play Services: an open-source alternative worth watching.

AARE is an open-source project aiming to reimplement the smartphone side of Android Auto, allowing apps to appear on your car’s display without relying on Google’s official solution.

Here’s what it offers:
🔹 Navigation with apps like CoMaps and Organic Maps
🔹 Music, podcasts and radio, including support for Navidrome
🔹 Messaging: Signal, WhatsApp and SMS, with message readout and replies while stopped
🔹 An alternative voice assistant
🔹 USB or wireless connectivity

The goal is to give users more freedom in their choice of apps while reducing their dependence on Google’s ecosystem.

One caveat: the project is still at an early stage of development. Compatibility and real-world performance in a car remain to be verified.

https://github.com/prototux/AARE

Would you choose AARE or Gearslip to move away from Android Auto and reduce your dependence on Google?

#Android #OpenSource #DeGoogle #Privacy

The Phermi Paradox

If #PHP2Shell is so gnarly and so many systems are vulnerable, why hasn't half the internet fallen over?

Couple possibilities:

1. The exploit is still non-trivial and building the full attack chain is taking some time.

This is at least partially true. I've yet to see a fully reliable proof-of-concept exploit that addresses all versions of PHP. Calif and Wiz showed exploit videos against targets. They didn't show what pregaming they did to prepare the exploit for those specific targets. So far, it seems like some prior work is necessary to get proper offsets, heap layouts, and payload shapes to exploit properly.

And that's assuming the mod_php SAPI, which responds differently to this than PHP-FPM.

2. Patching was aggressive and major targets had time to get in front of this.

For larger orgs, I believe this is accurate. The message was clear enough, and there was time enough to get any org with a half-awake IT team to circle the wagons. Patching isn't done, surely, but I think the most enticing targets for notable attacks probably moved quickly.

It's also worth noting that status dashboards like this are mostly a fairy tale. Look at the bottom for some whopper disclaimers. OS backports to versions other than PHP's official patched versions will muddy the picture, as will the 50% of PHP services that don't report versions. I'm not saying most of the internet is patched; I'm just saying we can't rely on these metrics as truth.

But let's not ignore the alternative:

3: The exploited won't know it's happening and won't report it.

This is hardly a new phenomenon PHP sites have been exploited for years without anyone noticing (see: Slot Gacor). Exploitation won't look like the internet blinking off. It'll look like a bunch of gambling pages and piracy hosted on school and municipal government websites. Such attacks can lie quietly on PHP sites for years before anyone bothers to look.

So yeah, just checking in. Doesn't seem like the internet fell over. Doesn't seem like we're seeing an autopwn exploit ruin everyone's day.

Patching quickly was prudent, but the initial comparison to Heartbleed/Log4Shell (including my own) was a bit hyperbolic.

I got hauled into a data center today because Claude was used to spec it and screwed up badly. At least 2,500 GPUs were in an impossible upside down and backwards plan.

😱

I had to pause the call because I couldn't stop laughing. AI had sabotaged the AI datacenter spec for building more AI.

“It’s a poor worksman who blames his tools” has always been complete nonsense. No-one complains about imperfect tools faster and louder than a master. A master will yank a cheap or damaged tool out of your hand and yell at you for not blaming it yet

Cheap, lousy tools come from middle managers who don’t know how to do your job. Blame the hell out of poor tools and those who demand you use them

RE: https://infosec.exchange/@ifin/117486308706972948

This is the power of community. IFIN Staff (it's more than just me!) reviewed this observables in detail to make sure they passed muster. These are behavioral indicators that go beyond a list of attacker IPs.

As promised, we've updated our #PHP2Shell story with detailed observable indicators. These are based on a broad review of working proofs-of-concept, and should yield high-fidelity hunts and detections. They've also been added to our MISP feed.

https://ifin.network/t/cve-2026-109618-cve-2026-109619-remote-code-execution-in-php/914

#ThreatIntel

"How are you doing?"

Me:

We will have useful detections for #PHP2Shell in our post and in MISP shortly. We're doing rigorous validation to make sure we don't provide nonsense.

I have arrived at a working PoC based on a GitHub repo. But there are signficant caveats. You need 3 precise things to make it work.

1. Initial offsets for functions are PHP version-specific, so you need those going in. That's annoying but easy.
2. Heap layout constants based on Zend MM's memory layout for the PHP build. You get this with GDB precisely on a PHP instance you control, or fuzzing a target—messy.
3. The specific shape of the payload to hit the OOM at the right point. This is largely based on memory limit settings in php.ini.

So there's some prior work to hit a vulnerable target. A PHP offset "rainbow table" may be somewhere or getting built, but those specifics may explain the lag in clear evidence of exploitation.

I have arrived at a working PoC based on a GitHub repo. But there are signficant caveats. You need 3 precise things to make it work.

1. Initial offsets for functions are PHP version-specific, so you need those going in. That's annoying but easy.
2. Heap layout constants based on Zend MM's memory layout for the PHP build. You get this with GDB precisely on a PHP instance you control, or fuzzing a target—messy.
3. The specific shape of the payload to hit the OOM at the right point. This is largely based on memory limit settings in php.ini.

So there's some prior work to hit a vulnerable target. A PHP offset "rainbow table" may be somewhere or getting built, but those specifics may explain the lag in clear evidence of exploitation.

Here's what I basically have so far:

1. Most of the attack logs you see online are folks firing off the GitHub PoCs.
2. The GitHub PoCs are junk.
3. I have one (1) PoC that reliably produces a crash, but requires very specific conditions to do anything else, and even then it's hit-and-miss. I'm not certain how globally exploitable this really is.

Here's what I basically have so far:

1. Most of the attack logs you see online are folks firing off the GitHub PoCs.
2. The GitHub PoCs are junk.
3. I have one (1) PoC that reliably produces a crash, but requires very specific conditions to do anything else, and even then it's hit-and-miss. I'm not certain how globally exploitable this really is.

I got it working

python3 exploit.py http://127.0.0.1:8081/index.php --lab --profile low --command 'whoami'
php2shell weapon | profile=low files=20 namelen=1MB spray=150 leak=auto cmd='whoami' attempts=8
stage flow: ARM -> P1 -> SPRAY/LEAK -> CALL (video: arming -> spraying -> leak -> call)
NOTE: final system() is ASLR/leak-gated; no leak -> MARKER crash receipt.
FPM/CGI/LSAPI = DoS-class (worker kill). Use --rearm on live multi-worker.

[arm ] body=25MB
[arm ] status=200 dt=60.10s OOM=False <- need pre-RINIT OOM to orphan

[p1 ] body=4MB
[p1 ] status=200 dt=0.04s OOM=False

[spray] s[]=150 t[]=149 last_dtor=0x4141414141414141 body=1232KB
[spray] status=200 dt=0.02s
[leak] no reflected banner pointer -> MARKER (ungated crash demo)
[call] no leak -> dtor=MARKER (ungated crash/marker receipt)
[call] dtor=0x4141414141414141 zend_call_function=0x4141414141355d51 (dtor-0xBE3F0) t[]=149 cmd='whoami'

[call] attempt 1/8 s[]=150 t[]=149 body=1271KB
[call] status=200 dt=0.02s
[call] EXEC marker (uid=/root:) -> system() ran