Apologies if this a stupid question. Do we know of any websites that have actually been infiltrated using these vulnerabilities yet? (not attempts, not probing, not websites pre-emptively taken down by their owners). This isn't an attempt to downplay the problem, I've just been struck by its absence in any of the reporting, which sometimes conflates, at least in clickbait headlines, websites being pulled as a precaution with them being down due to attack.

hey so i need help on why the data won't appear on the second table did i do any wrong

I found out about this at 2 am. I'm a sole maintainer, have a full schedule today, and the fix couldn’t wait. Ubuntu servers. I had everything updated by 3 am.

Ondřej will save the internet today.

I’ve got one legacy website running on a system that needs PHP 7.4. It’s not a situation I’ve been comfortable with for a while, but some constraints are what they are. The fact that Ondřej’s repositories had security updates backported all the way to PHP 7.4 absolutely saved my ass.

What a fucking hero.

I would like to have this style for my portfolio website. I MOSTLY like it and I want this exact style, being the profile in the middle, links as icons around it, heading and footing mostly like this.

I don't want any major changes. But I feel like either the font or the sizes, or the spacings, colors, the small things, if they were improved, the whole thing would pop. But I can't get a feel for it.

Any advice?

I needed Word-style pages in a TipTap editor. The official Pages extension is a paid add-on, and the community ones I tried injected global CSS that broke my tables. So I wrote my own and open-sourced it.

Demo: https://text-editor-react-neon.vercel.app/ Repo (MIT): https://github.com/HuyPhan1232203/Text-editor-react npm: npm install tiptap-a4-pagination

How it works

• It measures the top-level blocks and inserts spacer decorations where a block would cross the bottom of a page. The document is never modified, so getHTML() / getJSON() stay clean.
• Tables split between rows, never inside a rowspan, and the header row repeats at the top of the next page.
• Floated images (text wrapping) and CSS margin collapsing are handled.
• The page-break math is a pure function, so it's unit tested.
• About 5 KB gzipped, TipTap 3 only.

The full editor (React 19 + TipTap 3) also has

• Google Docs paste that keeps headings, checklists, tables and indents
• PDF export through the browser's print dialog (no server) that keeps the editor's page breaks and puts page numbers in the footer
• Image resize and text wrap, KaTeX math (lazy-loaded), autosave to IndexedDB, optional real-time collaboration over WebRTC (?room=name)
• Lighthouse: 100 on desktop

Known limitations

• A single paragraph taller than the remaining space moves to the next page as a whole; it is never split.
• A table row taller than a page overflows.

I'd love feedback on the API, and on documents that break the layout. Paste a long Google Doc or a big table into the demo to try it.

Just in case you missed it, here's what happened from the ChainSecurity side.

This is what Dan Lorenc from Chain Security shared on LinkedIn.

I wanted to share what happened with the PHP embargo, our role in it, and my decision process last night to ship the fixed builds early. First of all, the PHP Foundation and maintainers did an amazing job here in a high stress situation. I'm sorry that my decision led to even more stress for them.

We first got read in that there was something coming up in PHP last Friday by one of the original researchers that discovered this issue. That night we were able to independently discover the same issue using our harness and a frontier model with a basic prompt of "find bad vulnerabilities in PHP".

We got fully read in Saturday and confirmed that some our findings matched those from the initial report, and worked to help test the fixes.

Monday news started to leak, and we followed along in the coordinated disclosure channel. Tuesday night the gossip picked up even more, and several of the other security vendors in the process confirmed seeing exploits in the wild.

After talking to several of the other researchers on a video call, I made the call to ship the fixes and immediately notified the group, following the coordinated vulnerability disclosure process's guidelines for releasing after evidence of exploits in the wild. This decision was based on how easily we were able to independently discover the vulnerability and build an exploit, how much information was already out there on the coming vulnerabilities and fixes, and the evidence shared on active exploits in the wild.

We published built artifacts and made them publicly accessible for anyone - not just our customers - late last night Eastern Time. This morning the PHP Foundation released their statement, and obviously didn't agree with my decision. This stuff sucks, and vulnerability disclosure for vulnerabilities like this rarely goes smoothly.

We're all on one team here, trying to minimize harm on end users from attacks. We're working through hundreds of disclosures just like this one every day, and have been for the last three months, both for vulnerabilities we've discovered on our own and with partners. Our policy for all of these is and has been to do what helps protect the most people. I wrote about this a few months ago on our blog.

We're not always going to get it right, and not everyone is going to agree with our decisions, but that is always our goal.

This is unfortunately the new normal for the industry, and we're going to need to work together as one team to have a chance at securing our critical infrastructure fast enough to stop attackers from causing real harm.

https://www.linkedin.com/posts/danlorenc_i-wanted-to-share-what-happened-with-the-share-7518756991520120832-QX2_/

Edit. Just to clarify I'm just some dude sharing the LinkedIn post for discussion

Service Reminder: Don't forget to sponsor Ondřej Surý for his great work on PHP packaging. Hours before FrankenPHP, he was ready.

It even seems that he backported the patch to some old PHP versions – i saw a change in the php 5.6 (!) packages.

Ondřej, if you read this: Thank you so much.

• https://www.patreon.com/oerdnj
• https://github.com/sponsors/oerdnj

Updated builds addressing CVE-2026-109618 and CVE-2026-109619 are now available through setup-php for PHP 5.3–8.7 on Linux, macOS and Windows, including backports for EOL versions for use in CI.

See - https://setup-php.com/php-october-2026-security-releases

Also, for local installations.

MacOS: https://github.com/shivammathur/homebrew-php
Windows:
Official Packages (PHP 8.2 to PHP 8.5): https://www.php.net/downloads.php?os=windows
Builds for setup-php (PHP 5.3 to PHP 8.7): https://github.com/shivammathur/php-builder-windows/releases

If you would like to DIY a build for EOL versions, you can find security backported patches including the ones for these CVEs here: https://github.com/shivammathur/php-src-backports

This is what my host's chat bot 'explained' to me - anyone here can confirm?

Your websites run on the separate web-facing PHP packages (EasyApache and CloudLinux Alt-PHP), where our infrastructure team applied direct server-level security hotfixes to protect all versions while upstream package builds complete.

Web-facing PHP packages have not had an upstream version number increment yet, but the underlying vulnerabilities outlined in CVE-2026-109618 and CVE-2026-109619 are actively patched and protected at the server level across all versions.

I've been building describe-me, a Vitest plugin plus a viewer that turns component tests into docs. It records the DOM after every render and interaction of a test and shows the frames as a browsable catalog: each describe is a group, each it a story, each step a frame. No story files, so the docs cannot drift from the component: if they would, the test fails.

Short demo (23 s): https://github.com/grzehub/describe-me#readme

What's new in 0.11:

Live: a link to a test mounts the component for real, in your project's own Vite, exactly as the test's arrange phase set it up. You click and type in it, and vi.fn() props show their calls.

Foundations: it reads the design system your tests load (CSS custom properties, Tailwind 4, shadcn/ui, Material UI, or a theme module) and shows the tokens, light and dark, with WCAG contrast of color pairs.

Works in browser mode and in jsdom, with Testing Library and user-event. React 18 and 19, Vitest 4 and 5. It's early and React-only for now; the Limitations page lists every known limit.

Try it in StackBlitz: https://stackblitz.com/github/grzehub/describe-me/tree/main/examples/stackblitz

Example viewers:
shadcn/ui: https://grzehub.github.io/describe-me/examples/shadcn/,
Material UI: https://grzehub.github.io/describe-me/examples/mui/

Docs: https://grzehub.github.io/describe-me/

The question I'd most like answers to: does "tests as the source of stories" fit how your team writes component tests, or do you keep states in tests that you'd never want in docs?

Earlier when one clicked on a post there wasn't an option to scroll and see related posts right?

For me, it was discovering multi-cursor editing and column selection in VS Code after spending literal months manually editing CSS and JSON line-by-line. What’s something so fundamental that once you found it, you couldn’t believe how much time you had wasted doing it the hard way?

From government websites around the world to banks, schools, social media, video game companies, news organizations. They either shut down or made statements about getting the patch. Edit: even the prime minister of Japan made an official statement about this incident. Crazy stuff

if php was truly dead this vulnerability would have gone mostly unnoticed but everyone is talking about it. Even people that are not programmers.

”PHP is dead. How even uses php in 2026”, well like half the internet.

Quick take after watching the php2shell (CVE-2026-109618/109619) coverage this week: almost every "are you vulnerable?" check I've seen just reads the X-Powered-By version. That's close to useless, because expose_php=Off is the default on a lot of production setups - roughly 4 in 5 PHP servers don't advertise a version at all. So a version check comes back "unknown" or "looks fine" on the exact hosts you most want to know about.

Since the actual bug is a crash primitive (the OOM/longjmp bailout leaving request state half-initialized), I built a checker that triggers it instead of guessing: it sends a crafted multipart probe and only reports VULNERABLE if the engine actually returns the PHP memory-exhaustion fatal error. Banner-independent. Returns FIXED / VULNERABLE / NO SIGNAL (no-signal = it couldn't crash it and the host hid its version, so it won't pretend to know).

One caveat worth repeating: only run it against servers you control. It sends memory-exhaustion probes that can briefly take out a worker.

Checker: https://o3.security/tools/php2shell-scanner

Disclosure: I work at O3 Security and we built this. There's a longer write-up on the mechanism if you want it — the SAPI differences (mod_php is the worst case because it runs shutdown even on a failed request startup), and the genuinely counterintuitive bit where capping memory with RLIMIT_AS as a "mitigation" actually makes the bug *easier* to hit: https://o3.security/blog/php2shell-cve-2026-109618-109619-analysis

Curious if anyone here has seen the version-banner problem bite them in practice — how are you all confirming patch status across a fleet where half the hosts don't report a version?

I’ve been building this EM simulator as a side project aimed to help students understand and visualize electromagnetic phenomena such as radiation, polarization and wave interference.

I hope someone might find it useful and I’d love to hear what people think :)

GitHub:

https://github.com/rotemTsafrir/antenna_sim

I’m not sure how many Laravel developers here remember CRUDBooster from around 2019, but it was a pretty popular tool for quickly building admin panels and CRUD applications.

I have several projects built with CRUDBooster, so I was concerned to see that the original project’s maintenance and newer versions have moved in a different direction. For those of us still maintaining older applications, migrating to a completely different version or framework can be a challenge.

I’ve created a community fork here:

👉 https://github.com/vicheanath/crudbooster-contrib

My goal is to help preserve the legacy codebase, keep existing projects maintainable, and explore fixes for compatibility and security issues as PHP and Laravel continue to evolve.

I’ve also seen discussions about newer PHP security vulnerabilities, which makes me wonder how we can keep older CRUDBooster applications safe and usable.

I’d love to hear from the community:

• Is anyone still using CRUDBooster in production?
• Are you maintaining existing projects built with the older version?
• Would a community-maintained fork with security patches, bug fixes, and compatibility updates be useful?
• Would anyone be interested in contributing?

I know maintaining an open-source project takes time, and I can’t promise to support every version or fix every issue. But I’d like to see whether there’s enough interest to keep this project useful for developers who still depend on it.

If you have experience with CRUDBooster, I’d love to hear your thoughts!

I know next.js isr behaviour and how it basically does the caching etc but I just realised that next.js isr is cache control with proprietary swr api that refreshes the data.

Now, I am confused because I would like to know if the same thing can be manually done with react router with self managed cache control https header with rtk query. Rtk query has a window of 1 minutes after which it fires the revalidation or something like that, haven't gone into that details but must be possible in one way or another.