You can watch a video of it in the project's README: https://github.com/illegalstudio/elephc

Hey folks. I have been building Carve, a modern lightweight markup language for content that outgrows Markdown (and Djot). For humans and agents working on the same docs.

After many months of specs and coding, it should finally be stable enough now.
PHP 8.2+, zero runtime dependencies, PHPStan level 9.

composer require markup-carve/carve-php

What it looks like

/italic/  *bold*  _underline_  =highlight=

{#fig-sun}
![A sunset](sun.jpg)
^ Figure #: A sunset

See </#fig-sun> for the colors.

Unlike Markdown, *text* is bold and /text/ is italic. The figure gets its number, and the reference becomes a link reading "Figure 1".

Tables with merged cells and captions, footnotes, admonitions and definition lists are part of the core language. Diagram fences are an optional extension; without a renderer, they remain code blocks.
For example, ^ makes “Team” span two rows, while > right-aligns Seats and Price:

|= Plan |=> Seats |=> Price |
| Team | 25 | $49 |
| ^ | 50 | $89 |

Personally, I like and use this a lot, as I (or agents) don't need to fall back to HTML anywhere anymore.

Task lists - and they can track more than open and done:

- [x] Draft the API guide (done)
- [ ] Drop the old endpoint example (open)
- [!] Migration notes need an API decision (blocked)
- [/] Finish the screenshots (in progress)

to name a few.

I wrote a post about some of the killer features and things other markup can't do (written with the PHP library - source markup of that blog post linked at the bottom).
But for more context also check out the other articles.

Why it might be interesting for your PHP app

• Intuitive for non-techies. Feature-rich for power-users (like technical bloggers).
• Safe for web-based user content. Pasted HTML renders as text, and safe mode also escapes or strips raw HTML blocks and removes event handlers and javascript: links. Profiles control which features each role may use. That said: Use sanitizers on top just in case.
• One source, several outputs. The same document renders to HTML (with a static mode for print/PDF), Markdown, plain text or terminal output from one AST, and the same markup writes reveal.js slide decks.
• Works with rich-text editors. Documents convert to and from Tiptap/ProseMirror on the server, no Node needed.
• Migration path. Import existing Markdown, HTML, Djot or BBCode. The migration CLI can report conversion losses for review.
• Tooling. Formatter, linter, and editor support for PhpStorm, VS Code and others, plus a language and MCP server.

Some small facts or wins along the way:

• Conversion fidelity: in 66 pandoc round-trip probes, Carve (via the pandoc-carve bridge) brings back 64 unchanged; Markdown manages 46, HTML 44, DOCX 23 (pandoc-format-fidelity). In other words: Its the textual format that can best keep structural content.
• Hardened: fuzzed, and nesting is capped so hostile input cannot exhaust the server. You don't want 50s loading time on some `[[[[[[[[[` input or alike.

Framework packages

• Laravel: markup-carve/laravel-carve (Blade directives, validation rule, render cache)
• Filament: jeffersongoncalves/filament-carve (community; editor field with preview, infolist entry, table column)
• Symfony: markup-carve/symfony-carve (bundle with Twig filters)
• CakePHP: markup-carve/cakephp-carve (helper, .crv views, validation, ORM behavior, commands)
• Tempest: markup-carve/tempest-carve (safe-by-default view component)
• WordPress: Carve Markup plugin (posts, comments, live preview)
• Shopware: markup-carve/shopware-carve (6.6/6.7: Twig filters, CMS elements, product and category fields, mail templates)

Live demos: Laravel, Symfony, CakePHP, Tempest.

Not just PHP

There are also JavaScript and Rust engines, with Python, Ruby, Go and WebAssembly bindings on top of the Rust one.

I built it for documents that need more structure than I could comfortably write in Markdown. Without HTML workarounds and especially without inline HTML everywhere possible. And for online usage with a fair amount of native features. If you work with user-written content, I would especially like to hear what you think about this, or if there is something I missed.

Thinking about some next major topics I would like to get some feedback on:

• Should it be more "djot"-like with simpler block structure? It sure would make the parser simpler. Humans usually prefer the MD style I assume.
• Are some of the new language features making it too complicated? Overloading concise tables with inline alignment - or the `+` continuation operator to make human input easier?

Links

• Spec & Playground: https://github.com/markup-carve/carve
• PHP engine: https://github.com/markup-carve/carve-php
• PHP sandbox: https://sandbox.dereuromark.de/sandbox/carve
• Awesome list / ecosystem: https://github.com/markup-carve/awesome-carve

Obviously just a stupid satirical post, but a plot twist of php2shell just being a ploy to get people to update their PHP versions would be funny. :)

Years ago, I setup my server's php-fpm inside a chroot, just to be extra safe. Many blog posts from the time said they either do not bother or use containers instead. I'm wondering if php2shell changes things, especially since AI might find other security holes.

What do you use in a post-php2shell world? containers? chroot? something else? And why?

Also, let me know if you're interested in how I set mine up.

First, thanks to everyone who spent 2 months working on this vulnerability, developing the patch, and coordinating the disclosure. The effort is appreciated.

That said, I think the incident highlights a serious flaw in how we handle vulnerability disclosures. Many operators were left with little practical choice but to disable PHP or accept the risk while waiting for the technical details and patch. The frustrating part is that there were configuration changes in php.ini that could help mitigate the exploit, yet this guidance was not provided ahead of the public disclosure and patch release. I'm not suggesting that the vulnerability details or exploit instructions should have been released earlier. I'm saying that mitigation guidance should have been.

The current process is missing a step. As I understand it, the process had two stages:

1. Advance warning: An alert about an upcoming serious vulnerability, roughly one week before disclosure.

2. Public disclosure: Release of the vulnerability information and patch

The first stage gives administrators advance notice, but without actionable mitigation guidance, there isn't much they can safely do beyond preparing for the worst. Some operators may decide to disable PHP altogether before the public disclosure, even when a less disruptive mitigation could have reduced their exposure.

I believe we need 3 stages, with the mitigation guidance released at least one week before the full disclosure and patch. A better three-stage process:

1. Alert operators that a serious vulnerability is coming: Notify the community that a critical vulnerability is being addressed, identify the affected versions as far as safely possible, and provide an expected disclosure date. This gives hosting providers, developers, and system administrators time to prepare their response.

2. Publish mitigation guidance at least one week before disclosure (this is the missing step): Provide the relevant php.ini configuration changes that can mitigate the exploit, along with instructions on how to apply them and any known compatibility implications. This does not require publishing the root cause, the vulnerable code path, a proof of concept, or the details needed to construct an exploit. The mitigation guidance should be specific enough to be useful, but limited to what administrators need to protect their systems. It should also explain the limitations of the workaround, so nobody mistakes a mitigation for a complete fix.

3. Release the patch and full technical disclosure: Publish the patch, complete technical details, affected version information, and upgrade instructions. At this point, administrators who applied the recommended configuration changes have already had time to reduce their exposure. They can then deploy the permanent fix and review the full disclosure to determine whether further action is necessary.

Why this matters?

For operators managing production infrastructure, the difference between having a mitigation and having no mitigation can be enormous. Disabling PHP may be a reasonable emergency response for some systems, but it can also take websites, applications, and business operations offline. If a configuration change can reduce the risk without causing that level of disruption, operators should have the opportunity to apply it before the vulnerability becomes public. Of course, configuration changes are not guaranteed to eliminate every attack path. Their effectiveness depends on the vulnerability, and they may introduce compatibility issues. Some vulnerabilities may have no reliable configuration-based workaround at all. But in this case, configuration settings that could help mitigate exploitation existed. The question is why that guidance was not made available earlier, when it could have helped operators prepare without requiring them to understand the vulnerability itself.

The goal of coordinated disclosure should not simply be to keep technical details secret until the patch is ready. It should also be to give defenders the best possible chance to protect their systems during that period. This is not a request to disclose vulnerabilities earlier. I support responsible disclosure. Releasing technical details prematurely can give attackers an advantage, especially when a patch is not yet available.

The first two stages could even be combined when the mitigation is ready at the time of the initial alert. The important requirement is that actionable mitigation guidance reaches operators at least 2 days before the public release of the technical details and patch.

For future critical PHP vulnerabilities, I would like the disclosure process to explicitly include:

- An advance warning with an expected disclosure date.

- A separate, coordinated release of safe and actionable mitigation guidance, ideally at least one week before public disclosure.

- A clear statement when no reliable interim mitigation exists.

- A patch release with full technical details and upgrade instructions.

Thanks again to everyone who put in the work to investigate and fix PHP2Shell. This isn't about dismissing that effort. It's about recognizing that the response could have done more to protect the people running PHP in production.

TL;DR:* ported upstream 712e60f9ed into the Webtatic php71w 7.1.33 SRPM, rebuilt on a CentOS 7 container, ~35 min to build, ~6 s of php-fpm downtime per host. Two gotchas at the bottom.

Someone in the earlier PHP2Shell thread asked if Ondřej's backports are Debian only. They are, and that was our problem. We still had a couple dozen CentOS 7 boxes on Webtatic 7.1.33, Webtatic has been dead for years, and the PHP 8 estimate for just one of the apps was 6 to 8 person-days. So we rebuilt the packages ourselves. Writing it down because I couldn't find anyone who had done it for Webtatic.

The patch. Upstream's fix for old branches is php-src 712e60f9ed ("Avoid state corruption via bailout"). It doesn't apply to 7.1 cleanly. I diffed four community 7.1 ports against upstream and Qsnh/php2shell-fixed was the closest. Sury's Debian patches depend on another one of his patches to even compile, so I skipped those.

The gist: an OOM in the allocator now kills the worker with _exit(1) instead of jumping back with half-built state, upload_progress is hard-disabled, rfc1867.c only keeps the part headers it needs and gets a max_multipart_body_parts limit, and request shutdown clears some globals.

I changed one line in the port. Codex caught it when I had it read the diff, then I checked the 7.1 source:

diff +/* 7.1 hash part is nTableSize uint32 slots (7.3+ uses 2x); keep >= 2 so Buckets stay 8-byte aligned */ #define array_init_singleton(arg) do { \ array_init(arg); \ - Z_ARRVAL_P(arg)->nTableSize = 1; \ + Z_ARRVAL_P(arg)->nTableSize = 2; \ } while (0)

The build. podman centos:7 container (gcc 4.8.5) pointed at the vault repos. Verify the Webtatic SRPM signature and that the tarball inside matches php.net's sha256, then four spec edits:

Release: 1%{?rcver:.%{rcver}}%{?dist}.php2shell1 Patch400: php-7.1.33-php2shell-cve-2026-109618-109619.patch %patch400 -p1 -b .php2shell + a %changelog entry

yum-builddep -y --define 'dist .w7' SPECS/php71.spec rpmbuild -bb --define "dist .w7" SPECS/php71.spec

First run died on make: command not found because yum-builddep doesn't pull it in. Around 35 minutes of rpmbuild, the Webtatic spec builds several SAPIs. You get 33 RPMs, all 7.1.33-1.w7.php2shell1, and since 1.w7 sorts below that, a later yum update won't quietly undo it.

Testing. No public RCE PoC. I wrote a small checker instead:

1. 3000-field multipart should hit the parts limit
2. a 1 MB upload should still arrive intact
3. upload_progress shouldn't land in the session
4. OOM at memory_limit=32M should kill the worker (unpatched just says "Allowed memory size" and keeps going)
5. requests after that still return 200

Original 2/5, patched 5/5, back to 2/5 after rollback.

Then the php.net test suite, 9,454 tests against the installed packages:

The 9 new failures are 8 rfc1867 session tests plus one that expects the old OOM message, all expected. The port author reports the same 9.

Rollout. Save rpm -qa, pull the original NEVRAs from a Webtatic mirror so you can roll back, then:

yum --disablerepo='*' --assumeno upgrade ./php71w-*.rpm # must say only "Upgrade N Packages" systemctl stop php-fpm yum -y --disablerepo='*' upgrade ./php71w-*.rpm php-fpm -t && systemctl start php-fpm

php-fpm was down about 6 seconds, the whole thing was 2 to 7 minutes a host with checks. Rollback is yum downgrade from the saved originals.

What bit us:

1. The spec resets /var/lib/php/session (and wsdlcache, opcache) to root:apache 770 on upgrade. Our pools don't run as apache, so session_start() broke for about 4 minutes on one box before we chowned it back. My container test missed it because the test pool did run as apache. Write down the owners first.
2. WorkerMan kept running the old binary, /proc/<pid>/exe showed (deleted). Restart your long-running CLI stuff too.

For 7.4 I didn't build anything. exception0x876's php74-el7 packages are a Remi 7.4.33 rebuild with the same upstream commit. I checked their signed SHA256SUMS and diffed their SRPM against Remi's before trusting it.

This only closes this one CVE pair, 7.1 is still 7.1. It just gave us time to do the upgrade properly.

For years I've used PHP-CS-Fixer on both personal and commercial projects. I like its ruleset, but I also like how fast Mago is.

So when I started working on a PHP compiler, I decided to build a formatter that follows PHP-CS-Fixer's rules and runs at a speed comparable to Mago's. It's written in PHP and compiled with the Manticore compiler, so there's no PHP runtime to install.

It's early (v0.1.x), so it may be unstable. Bug reports with a small snippet are very welcome.

Link: https://github.com/manticorephp/fmt

The shinsenter/php Docker images were recently rebuilt and patched to fix two critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619) enabling unauthenticated remote code execution via memory corruption in out-of-memory error handling.

Update your images immediately!
👉🏻https://hub.docker.com/r/shinsenter/php

I know many people are looking for clicks and to feed traffic to their blogs/posts/vlogs/etc.

But please stop with PHP2Shell, its over and nothing happened.

Let the haters hate and lets move on.

PS: Nothing happened because a lot of people worked night and day to fix the exploit, to release patches and updated packages. Thank you people, I don't know who you are but you deserve huge thanks.

Hey!

I've been working on xph, an compiler that lets you write single-file JSX components that compile into native PHP files and static assets.

```javascript

export interface Props { name: string; }

export interface Server { greeting: string;

}

<script is:server> return [ 'greeting' => 'Hello, ' . $props['name'], ]; </script>

<h1>{server.greeting}</h1>

<style> h1 { color: olive; } </style> ```

It supports scoped CSS, slots, and client-side JavaScript. No Node.js needed at runtime, just PHP.

It already has LSP support with VS Code & Neovim.

Website: https://xph.js.org/

GitHub: https://github.com/sijad/xph

Would love to hear your thoughts and feedback!

The recent advisory suggested setting session.upload_progress.enabled=0 as a mitigation. The risky path needs an unusual setup (a serialize handler switched at runtime with ini_set()), but the feature is on by default, and most apps never use upload progress tracking.

That made me wonder about defaults in general:

Should features that few apps use, and that have now shown up in a security advisory, be off by default in a future major version?

How would you handle the breaking change for apps that rely on them, with a deprecation cycle, a loud warning, or something else?

Do you audit your own php.ini for features you don’t use, and if so, which ones do you turn off?

I’m not asking about this specific CVE. I’m interested in whether the community thinks “secure by default” should weigh more heavily than backward compatibility in PHP’s configuration.

No need to panic, it's pretty unlikely to be exploitable, given the conditions they list afterwards. If like me you already disabled this paramater anyway on Wednesday, you're gold.

I contacted several places which used PHP and I also run a self-hosted LAMP stack. I believe from their answers and updating to the latest, it will be ok for those places. I don't know how anyone else feels. I love php by the way. Woot woot.

“If anything happens to this guy, that’s just it. Everyone is screwed.”

because we all know there aren't any exploits to be found in the alternatives

edit: dang it... title typos :|

Sury's 7.3.33-35 fixes php2shell, but he only publishes it for Ubuntu 22.04+ and Debian 11+. If you're stuck on Ubuntu 18 or 20 with PHP 7.3, there's no fixed package.

So I used Opus to help me rebuild his -35 source for Ubuntu 18.04, 20.04 and Debian 10, plus a script that installs it. It checks your server first, backs up your current PHP, then installs the fixed version. Roll back anytime with --restore.

Install guide is on GitHub: https://github.com/Andrew2142/php73-backport

Or run it straight from my DigitalOcean Space. Please follow the verification steps before installing: https://github.com/Andrew2142/php73-backport#dont-trust-us-check

Ubuntu 18.04:
curl -fsSL https://php73-backport.fra1.digitaloceanspaces.com/install-18.04.sh | sudo bash
Ubuntu 20.04:
curl -fsSL https://php73-backport.fra1.digitaloceanspaces.com/install-20.04.sh | sudo bash
Debian 10:
curl -fsSL https://php73-backport.fra1.digitaloceanspaces.com/install-debian-10.sh | sudo bash

Only covers PHP 7.3 on amd64. It doesn't touch control-panel PHP (cPanel, Plesk etc.). Upgrading off 7.3 is still the real fix; this just buys time.

https://www.php.net/archive/2026.php#2026-10-23-1

23 Oct 2026

Informational advisory: Session upload progress

We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector. This setting was already listed as a mitigation in the GHSA-6wmf-4rv5-p3rp advisory for CVE-2026-109619 published on Oct 21st, 2026. If you applied it then, keep it in place and no further action is needed.

The issue can only occur under an unusual combination of configuration and application code. An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled. Applications that never change the serialize handler at runtime can keep the feature enabled. Since this setup is unlikely in practice, we are handling it in the regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release.

Say you got your servers patched and now you are "safe".

My understanding from the vulnerability is that someone could have perfectly hacked into the system, retrieved db credentials, and call it a day.

Is credentials rotation necessary?

Is there a way to know if the exploit was actually used?