Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #94572 > unrolled thread

PHP2Shell

Back to article view | Back to comp.os.linux.misc

Contents

  PHP2Shell The Natural Philosopher <tnp@invalid.invalid> - 2026-10-22 19:16 +0100
    Re: PHP2Shell Andy Burns <usenet@andyburns.uk> - 2026-10-22 19:28 +0100
      Re: PHP2Shell The Natural Philosopher <tnp@invalid.invalid> - 2026-10-22 19:36 +0100
        Re: PHP2Shell Andy Burns <usenet@andyburns.uk> - 2026-10-22 19:45 +0100
          Re: PHP2Shell The Natural Philosopher <tnp@invalid.invalid> - 2026-10-22 19:50 +0100
          Re: PHP2Shell doctor@doctor.nl2k.ab.ca (The Doctor) - 2026-10-23 01:59 +0000
    Re: PHP2Shell Richard Kettlewell <invalid@invalid.invalid> - 2026-10-22 19:58 +0100
      Re: PHP2Shell Nuno Silva <nunojsilva@invalid.invalid> - 2026-10-23 00:39 +0100

#94572 — PHP2Shell

Hundreds of articles about it but none detailing exactly how the 
exploits work
Anyone know?
-- 
Climate Change: Socialism wearing a lab coat.

[toc] | [next] | [standalone]

#94574

The Natural Philosopher wrote:

> Hundreds of articles about it but none detailing exactly how the 
> exploits work
> Anyone know?

Don't think full details have been released yet because the fix got 
leaked before the time the embargo was due to be lifted (about now 
rather than yesterday).

Some hints in the CVEs ...

"PHP enforces its user-configurable memory_limit by using longjmp() to 
abort any request that exceeds the limit, which raises an OOM error. 
This can interrupt PHP while internal request data is only partially 
initialised"

"Internal state owned by a request can survive after its backing memory 
has been freed, for example after a fatal error. A later request handled 
by the same worker may use that stale state before normal initialisation 
resets it."

[toc] | [prev] | [next] | [standalone]

#94577

On 22/10/2026 19:28, Andy Burns wrote:
> The Natural Philosopher wrote:
> 
>> Hundreds of articles about it but none detailing exactly how the 
>> exploits work
>> Anyone know?
> 
> Don't think full details have been released yet because the fix got 
> leaked before the time the embargo was due to be lifted (about now 
> rather than yesterday).
> 
> Some hints in the CVEs ...
> 
> "PHP enforces its user-configurable memory_limit by using longjmp() to 
> abort any request that exceeds the limit, which raises an OOM error. 
> This can interrupt PHP while internal request data is only partially 
> initialised"
> 
> "Internal state owned by a request can survive after its backing memory 
> has been freed, for example after a fatal error. A later request handled 
> by the same worker may use that stale state before normal initialisation 
> resets it."

That sounds like it is only relevant to large uploads: If the code 
doesn't permit that you should be safe?


-- 
    "Fanaticism consists in redoubling your effort when you have 
forgotten your aim."

  George Santayana

[toc] | [prev] | [next] | [standalone]

#94579

The Natural Philosopher wrote:

> That sounds like it is only relevant to large uploads: If the code 
> doesn't permit that you should be safe?

I did hear that causing the exploit depended on uploads, but wasn't sure 
enough that no uploads made it safe, so did recommend one customer to 
shut their customer portal down.

The code is written/hosted by a 3rd party, I just point the DNS at it.

[toc] | [prev] | [next] | [standalone]

#94581

On 22/10/2026 19:45, Andy Burns wrote:
> The Natural Philosopher wrote:
> 
>> That sounds like it is only relevant to large uploads: If the code 
>> doesn't permit that you should be safe?
> 
> I did hear that causing the exploit depended on uploads, but wasn't sure 
> enough that no uploads made it safe, so did recommend one customer to 
> shut their customer portal down.
> 
> The code is written/hosted by a 3rd party, I just point the DNS at it.
Ah.

Yes. I've blown PHP up with large uploads. And downloads. So I wrote the 
handler for those in C.

I don't think any of my sites allow user upload beyond half a dozen 
parameters.

Well that's a starting point: No doubt other stuff will emerge in due course

-- 
Ideas are more powerful than guns. We would not let our enemies have 
guns, why should we let them have ideas?

Josef Stalin

[toc] | [prev] | [next] | [standalone]

#94597

In article <njv3ugFjuhmU1@mid.individual.net>,
Andy Burns  <usenet@andyburns.uk> wrote:
>The Natural Philosopher wrote:
>
>> That sounds like it is only relevant to large uploads: If the code 
>> doesn't permit that you should be safe?
>
>I did hear that causing the exploit depended on uploads, but wasn't sure 
>enough that no uploads made it safe, so did recommend one customer to 
>shut their customer portal down.
>
>The code is written/hosted by a 3rd party, I just point the DNS at it.

PHP2SsHELL

derived from PHPsHELL?
-- 
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ; 31 years in the ISP business!

[toc] | [prev] | [next] | [standalone]

#94582

The Natural Philosopher <tnp@invalid.invalid> writes:
> Hundreds of articles about it but none detailing exactly how the
> exploits work
> Anyone know?

The advisories sketch what the bugs look like:

https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

Briefly, error paths don’t clean up internal state adequately, and leave
invalid states (e.g. pointers to freed data, wrong array bounds, etc)
which can be exploited during subsequent requests.

More details, with (roughly) increasing levels of detail from one to the
next, can be found here:

https://www.wiz.io/blog/php2shell-php-rce
https://www.crowdstrike.com/en-us/blog/crowdstrike-protects-customers-from-php-rce-zero-days/
https://calif.io/php2shell/

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#94591

On 2026-10-22, Richard Kettlewell wrote:

> The Natural Philosopher <tnp@invalid.invalid> writes:
>> Hundreds of articles about it but none detailing exactly how the
>> exploits work
>> Anyone know?
>
> The advisories sketch what the bugs look like:
>
> https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
> https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
>
> Briefly, error paths don’t clean up internal state adequately, and leave
> invalid states (e.g. pointers to freed data, wrong array bounds, etc)
> which can be exploited during subsequent requests.
>
> More details, with (roughly) increasing levels of detail from one to the
> next, can be found here:
>
> https://www.wiz.io/blog/php2shell-php-rce
> https://www.crowdstrike.com/en-us/blog/crowdstrike-protects-customers-from-php-rce-zero-days/

Well yes, given a containment measure that has been mentioned has been
to shut down php-based services, Crowdstrike does sound like the place
to go for that, they surely have experience in making managed systems
unavailable.

> https://calif.io/php2shell/

-- 
Nuno Silva

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web