36
Channel to sync with /r/PHP /r/Laravel /r/Symfony. Powered by awesome @r_channels and @reddit2telegram
I made a pixel-art Halloween quest to resurrect RoadRunner. Live run Oct 31 at 16:00 UTC 🎃
https://halloween.roadrunner.dev
https://redd.it/1xjqs27
@r_php
cookies, etc.
- It receives remote code and executes it.
- It has some obfuscated code to detect legitimate plugins, it modifies some of them.
Interestingly, it uses wp_generate_auth_cookie() to generate an admin session that sends this back to its control server, thus the attacker can login to wordpress without knowing the password of the admin.
On the front-end side, it adds Javascript code that runs its own Service Worker for intercepting web traffic.
It does various other things that I can't be bothered to write about :)
---
I also posted this in /r/Wordpress but the post was removed by the moderators, so I'm posting on /r/PHP to raise awareness
https://redd.it/1xjm5pt
@r_php
SymfonyCon Warsaw 2026: Headless vs Monolith: The Final Battle
https://symfony.com/blog/symfonycon-warsaw-2026-headless-vs-monolith-the-final-battle?utm_source=Symfony%20Blog%20Feed&utm_medium=feed
https://redd.it/1xjhhsp
@r_php
PHP2Shell: How We Secured a Legacy PHP Application in Four Hours
# TL;DR
On October 22, 2026, our engineering team responded to two critical PHP Remote Code Execution (RCE) vulnerabilities disclosed as part of the PHP2Shell security incident.
One of our legacy services, responsible for document verification, media storage and file attachments, was running on an outdated PHP version that was potentially vulnerable to these security issues.
We decided to upgrade it immediately rather than wait for the next maintenance window.
Within four hours, our engineering team upgraded the PHP environment, resolved compatibility issues, and tested the critical application flows.
The upgrade involved one planned downtime window of approximately 30 minutes. By 6 AM, the service was running on an updated and patched PHP release and had passed our validation checks.
Here's how we approached the upgrade, the challenges we faced, and what we learned from the experience.
# 1. Identifying the Vulnerable Service
During our infrastructure assessment, we identified one legacy CodeIgniter service that required immediate attention.
This service was responsible for:
User document verification.
Media and image storage.
File uploads and attachments.
File-system operations related to user documents.
The service was running on an outdated PHP version that had reached end of life and was no longer receiving regular upstream security updates.
There were two primary concerns:
1. The service was accessible from the internet.
2. It was running on an outdated PHP runtime that could leave it exposed to known security vulnerabilities.
With critical RCE vulnerabilities now disclosed, continuing to run this service without upgrading its PHP environment was a risk we didn't want to take.
We decided to upgrade the service immediately.
# 2. Planning the Upgrade
A PHP version upgrade requires more than installing a newer runtime.
Major PHP version changes can introduce compatibility issues, deprecated functionality, extension incompatibilities and dependency requirements.
An upgrade without proper validation could break existing application functionality.
We considered these factors before proceeding.
Between 2 AM and 6 AM, our platform generally receives significantly less traffic than during regular business hours. This provided a better opportunity to perform the upgrade while minimizing disruption to users.
Rather than postpone a critical security update, we decided to perform the upgrade directly on production during the low-traffic window.
# 3. The Four-Hour Upgrade: 2 AM to 6 AM
Our CTO identified the security advisory on X (formerly Twitter) and immediately alerted the engineering team.
Within minutes, the entire development team was online.
We divided the work into identifying the affected environment, upgrading PHP, resolving compatibility issues and validating the application.
Here's the timeline.
# 2:00 AM – Incident Identification
The team came online following the CTO's alert.
We identified the affected service and confirmed that it was running an outdated PHP version.
We reviewed the existing environment and prepared for the upgrade.
The immediate objective was to move the service to a patched PHP release without introducing application-level issues.
# 2:00 AM – 4:30 AM – PHP Upgrade and Compatibility Fixes
We started upgrading the PHP environment to a supported and patched release.
This involved more than a routine security update. The upgrade introduced compatibility challenges because some existing packages and application code relied on deprecated functionality.
The team worked through these issues and made the required changes to ensure that the application could run correctly on the updated PHP environment.
During this process, the service experienced approximately 30 minutes of planned downtime.
# 4:30 AM – 5:30 AM – Application Testing
After completing the PHP upgrade, we focused on validating the application.
Since this service handles important user operations, simply checking whether the
New in Symfony 8.2: Recovering from Controller Attribute Failures
https://symfony.com/blog/new-in-symfony-8-2-recovering-from-controller-attribute-failures?utm_source=Symfony%20Blog%20Feed&utm_medium=feed
https://redd.it/1xjd9hx
@r_php
Stackapella: an open source Laravel app for singing harmony
Hi all,
I just launched Stackapella, an open source app for learning harmony parts and recording all the voices of a song yourself. The backend is Laravel 13 with MySQL and the frontend is Vue loaded from a CDN, no build step.
\- Code: https://github.com/stackapella/stackapella
\- App: https://stackapella.com/?ref=reddit-laravel
Happy to answer questions, and any feedback on the code is welcome.
https://redd.it/1xjb017
@r_php
Something feels off about this subreddit lately
I don't know if it's just me, but ever since last week (October 21 / php2shell), this subreddit has felt completely out of control.
It honestly doesn't feel like the same community I used to know anymore, and at least to me, it seems to be heading in the wrong direction.
I get that the php2shell caused a lot of attention, and that new people are naturally going to have questions about it. But at the same time, there seems to have been a noticeable increase in spam and low-effort posts that end up sitting at 0 upvotes.
Is it just me?
(I propably go touch a some grass for a moth and hope its just temporary)
https://redd.it/1xigptb
@r_php
This Week in PHP Internals | Oct 29, 2026
https://youtu.be/oeDHs-qXXwA
https://redd.it/1xix6f5
@r_php
This Week in PHP Internals | Oct 29, 2026
https://youtu.be/oeDHs-qXXwA
https://redd.it/1xix9qe
@r_php
Symfony AI & MCP Hackathon: Meet the Jury, and What You Can Win
https://symfony.com/blog/symfony-ai-and-mcp-hackathon-meet-the-jury-and-what-you-can-win?utm_source=Symfony%20Blog%20Feed&utm_medium=feed
https://redd.it/1xigp90
@r_php
I open-sourced chatVia.ai, a self-hosted RAG chat platform built on Laravel 13
After about a year of work I've put the full source of chatVia.ai on GitHub: https://github.com/chatvia/chatvia
It's a self-hosted platform for AI chat agents that answer from your own knowledge (files, websites, text, Q&A, audio and video). Everything stays on your server except the calls to the AI provider you pick, and each agent can use a different model, including open-weight ones.
The stack is pure Laravel ecosystem:
Laravel 13, PHP 8.5, Pest 5, Horizon, Reverb
Inertia 3 + Vue 3.5 + TypeScript 6, Tailwind 4
Filament 5 for the admin panel
PostgreSQL 18 with pgvector for hybrid search (vectors + keywords), no separate vector DB
Laravel MCP for the built-in tool servers, plus any external MCP server or your own functions
Features: hosted chat page, website widget, command bar, WhatsApp, Messenger, Instagram, Slack, Teams and Telegram channels, human handoff with a live inbox, guardrails, tool-call approval and audit log, forms and lead capture, analytics, evals, REST API, one-command Docker install.
Some Laravel things:
Strict layering (App / Domain / Support) enforced by architecture tests in Pest
Streaming chat turns over SSE with a tool loop, and the same per-turn gates reused by every messaging channel
Workspace tenancy where another workspace's record is a 404, swept by a route test
Admin options as spatie/laravel-settings classes copied into config() at boot
Happy to answer questions about the architecture or the RAG pipeline.
https://redd.it/1xiqa8j
@r_php
PHP CLI workers don’t share opcache, so I made them: 70–80% less memory for Laravel queues
PHP's CLI doesn't share opcache between separately started processes, so every long-running worker compiles your whole app into its own private memory. With 8 Laravel queue workers that's 8 copies of the same compiled code, often 50–80 MB each.
I built queue-prefork to fix that for Laravel's `queue:work` and Horizon:
* A small template process starts with opcache and **no app code**.
* Each worker is forked from it with `pcntl_fork()` and then boots the app itself from the normal `artisan` entry. So nothing booted is inherited: no DB or Redis connections, sockets, singletons or RNG state. Only the compiled code is shared, through opcache's shared memory.
* The pid your process manager started stays (a tiny `/bin/sh` stub for `queue:work`), so supervisord or systemd signals, timeouts and restarts behave as before.
Side-by-side benchmark, two identical Docker stacks on the same job stream, Laravel 13 with \~45 packages, 1 h each:
|Setup|Stock|Prefork|
|:-|:-|:-|
|8 × queue:work, typical jobs|645 MB|192 MB (−70%)|
|8 × queue:work, idle|455 MB|102 MB (−78%)|
|8 × queue:work, heavy jobs|1,025 MB|524 MB (−49%)|
|Horizon, 6 supervisors|1,279 MB|240 MB (−81%)|
Same throughput, 0 failed jobs, and less CPU, since new workers don't recompile anything. If any safety check fails, workers run as stock and the package tells you why.
Linux only for production; Laravel 11–13. MIT: [https://github.com/tevkert/queue-prefork](https://github.com/tevkert/queue-prefork)
Happy to answer questions about the fork and opcache side.
https://redd.it/1ximb5x
@r_php
About the security entries in Symfony 5.4.55, 6.4.49, 7.4.22 and 8.1.10
https://symfony.com/blog/about-the-security-entries-in-symfony-5-4-55-6-4-49-7-4-22-and-8-1-10?utm_source=Symfony%20Blog%20Feed&utm_medium=feed
https://redd.it/1xigp8n
@r_php
Composer 2.11 Released - Cooldown Periods
https://blog.packagist.com/composer-2-11-release/
https://redd.it/1xigv61
@r_php
Sonic PHP
https://sonic.mimichat.fr/
https://redd.it/1xhnjm8
@r_php
PHP Doom (powered by PHP FFI and Vulkan API with ray tracing)
https://github.com/SerafimArts/PHP-Doom
https://redd.it/1xjmjqs
@r_php
Site compromised, interesting implementation of a persistent virus
Hello PHPers :)
I was tasked to look into two compromised WordPress sites. The people who own them, tried to remove the virus but failed. I wanted to describe what the virus was doing.
Overall this is a self-propagating, self-healing, obfuscated, hidden executor virus with size-padding evasion tactics.
It generated the following files and directories:
- /home/foobar/publichtml/wp-content/.sc494g1672
- /home/foobar/publichtml/wp-content/.gkeb46c3gc
- /home/foobar/publichtml/wp-content/.kkcb505c82
- /home/foobar/publichtml/wp-content/ab743742.zip
- /home/foobar/publichtml/wp-content/uploads/2026/10/ab743742.zip
- /home/foobar/publichtml/wp-content/plugins/agile-beacon-go
- /home/foobar/publichtml/wp-content/plugins/hyper-proxy-cue
- /home/foobar/publichtml/wp-content/plugins/nexus-curator-rig
- /home/foobar/publichtml/wp-content/plugins/swift-keeper-dex
- /home/foobar/publichtml/wp-content/mu-plugins/.bthyper-proxy-cue
- /home/foobar/publichtml/wp-content/mu-plugins/.pvhyper-proxy-cue
- /home/foobar/publichtml/wp-content/mu-plugins/.sdhyper-proxy-cue
- /home/foobar/publichtml/wp-content/mu-plugins/.swmhyper-proxy-cue
- /home/foobar/publichtml/wp-content/mu-plugins/hyper-proxy-cue.php
- /home/foobar/publichtml/mu-plugins/hyper-proxy-cue.php
Each compromised site received its own hash, thus the ab743742 you see above is the unique hash for this compromised site. The value re-appears in several places.
The virus infects the functions.php of the current theme, it adds a variable with the contents of the ab743742.zip file. When the site runs, the variable contents are gzdecode'ed gzinflat'ed and stored as the above zip file, which gets extracted under the plugins directory.
The virus generates a self-preserving "must-use" plugin under the mu-plugins directory.
The virus creates its own admin user in the SQL table wp_users and modifies WordPress files so that its own admin user is invisible.
Finally, the virus creates the .sc_[HASH VALUE] directory under wp-content which stores a specially crafted PHP cli script. This script is executed via exec() or other similar function, once its loaded the script deletes itself so it only remains resident in memory. This monitors all the above files and re-generates the whole infection.
At first glance, the virus tries to access a master server and receives instructions. In this case, it started adding hidden URLs inside the generated WordPress pages.
A few interesting things about this virus:
- It uses token_get_all() to validate its own PHP syntax before making modifications to the site, so that does not corrupt the site and get noticed.
- It uses function_exists() to test for various functions, so it can understand what it can do to its host server.
- It generates a padding size for modified files, so that it matches the target size and avoid detection from scanners that check file size.
- It generates various "sidecar" files with quality markers in MD5, a version file, rate limits (regenerate itself every 4 minutes) and a write race/lock flag.
- It executes hidden commands from wp-content/.sc_[HASH VALUE}.php files that act as commands imported from its master control server.
The following strings can used to grep/search for the infection:
- SCV:
- SCTHBEGIN
- hyper-proxy-cue
- scfam
- sccommit
Let me know if you need more details!
---
EDIT with information about the plugin
The plugin has its own replication and cleanup code. It detects the presence of itself by looking for the string /* SCV:x.x.x */ where x.x.x is the version number of the virus. If there is a newer version then it overwrites itself.
It replicates by scanning various directories like /home, /var/www. It also modifies advanced-cache.php and object-cache.php.
The main code does:
- List Ethereum JSON-RPC endpoints and contract addresses.
- Receives an Ethereum contract with remote commands.
- It sends server information like domain, plugins, admin users+passwords, session
application loaded successfully wasn't enough.
We tested the critical functionality, including:
Document verification flows.
File upload functionality.
Media storage.
Attachment handling.
Application compatibility with the updated PHP environment.
We also resolved the compatibility issues identified during testing.
# 5:30 AM – 6:00 AM – Final Verification
Before completing the upgrade, we performed final environment and application checks.
One important verification was checking the PHP version used by the actual web server.
Checking the CLI version alone isn't sufficient because the web application may use a different PHP-FPM runtime.
We verified that the PHP runtime serving web requests was using the updated environment.
We also checked the critical application flows to ensure that the service was functioning as expected.
By approximately 6 AM, the upgrade and validation were complete.
In approximately four hours, we had moved the affected service from an outdated and potentially vulnerable PHP environment to a patched release.
# 4. The Outcome
The engineering team completed the upgrade within the planned maintenance window.
The key outcomes were:
Upgraded the PHP environment to address the identified security risks.
Addressed PHP compatibility and deprecated functionality issues.
Completed testing of critical document and media-related functionality.
Limited production disruption to approximately 30 minutes of planned downtime.
Verified that the web application was running on the updated PHP runtime.
Most importantly, we addressed the vulnerable runtime without waiting for a regular maintenance cycle.
# 5. What We Learned
Although the upgrade was completed successfully, the incident highlighted a few areas where we can improve our engineering and infrastructure practices.
# 1. Security Updates Cannot Wait
Critical vulnerabilities in widely used technologies require immediate attention.
We need to continuously monitor security advisories and prioritize updates based on the actual exposure and risk to our production systems.
Security patching should be part of regular engineering operations, not something we only do when an incident occurs.
# 2. Legacy Applications Need Regular Maintenance
Applications can continue working for years without obvious problems, but that doesn't mean their underlying infrastructure is secure.
Our experience highlighted the importance of regularly reviewing PHP versions, dependencies and other infrastructure components used by legacy services.
# 3. Security Monitoring Should Be Automated
This incident was identified after our CTO came across the advisory on X.
While that helped us respond quickly, security monitoring should not depend on someone manually checking social media or security announcements.
We want to integrate security advisories and vulnerability alerts into our existing monitoring and notification systems so that critical issues reach the engineering team automatically.
# Conclusion
The PHP2Shell incident reminded us how quickly a vulnerability in a widely used technology can become an infrastructure priority.
We identified an outdated PHP environment, brought the engineering team together, and completed the upgrade to a patched release within approximately four hours.
The upgrade involved compatibility fixes, application testing and a short period of planned downtime.
There are still improvements we want to make, particularly around legacy application maintenance, staging environments and automated security monitoring.
But this experience reinforced an important principle for our engineering team:
Building reliable software is not just about shipping new features. It's also about continuously maintaining, securing and improving the systems that our users depend on.
https://redd.it/1xjcgzl
@r_php
phpscript: a go php-syntax runtime
https://incubator.to/u/titpetric/phpscript/phpscript-a-go-php-syntax-runtime
https://redd.it/1xjd0z9
@r_php
GuardedChatBundle: guardrails for public AI chat endpoints on top of Symfony AI
Disclosure: I wrote this.
If you put a Symfony AI agent behind a public, anonymous chat endpoint, the model call is the easy part. The work is everything around it: bots draining your token budget, session handling, retention, and a way to switch the chat off when something goes wrong. I extracted what I built for my own site into a bundle, stejac/guarded-chat-bundle.
What it does:
a prefilter for obvious prompt-injection phrases, as a plain input processor, so the model is never called for those
rate limits per client, a message cap per session and a budget stop
signed session tokens with a lifetime and an idle timeout
versioned prompts in the database, editable without a deploy
a two-stage kill switch and scheduled retention for old conversations
a Stimulus chat widget with a notice that an AI is answering
It complements Symfony AI instead of replacing it. When a guardrail PR for core was closed, the maintainers suggested a standalone package on top of symfony/ai-agent, so this is one take on that. I wrote up a few observations from building it in symfony/ai#1524: https://github.com/symfony/ai/issues/1524#issuecomment-6360524923
One caveat: the phrase filter is no security boundary, it only catches the obvious attempts. Rate limits and budget caps matter more on a public endpoint.
PHP 8.3+, Symfony 7.4 or 8.0, MIT. The Flex recipe is still pending in recipes-contrib, so for now the config files are created by hand (see README).
GitHub: https://github.com/Stefan39/GuardedChatBundle
Feedback welcome, especially on what you would expect from a guardrail layer like this.
https://redd.it/1xjbpwd
@r_php
Canvas: an open-source PHP framework that runs alongside your legacy code
I’ve been building Canvas, an open-source PHP framework. I built it for myself. It started because I wanted to modernize an existing PHP application incrementally and couldn’t get the integration I wanted with Symfony. Over time it grew into a standalone framework for building new applications that can also run alongside existing PHP code. I’m happily using it in my projects because it works the way I like it to, and I open sourced it so anyone who wants to can use it too.
It is deliberately similar to Symfony in some regards: it’s built on Symfony’s HttpFoundation, routes are annotations on controller methods, and the ORM is a Data Mapper like Doctrine. Where it differs:
Legacy Bridge: Canvas checks its own routes first. If it does not find a match, it will fall through to your existing PHP files. E.g. The Strangler Fig Pattern. Legacy files can use Canvas services through a canvas() helper.
AOP for cross-cutting concerns: instead of a middleware pipeline or kernel events, authentication, logging and caching are aspects declared with InterceptWith on a controller method or class, with before/around/after phases and priorities. Aspects are inherited, so a base controller’s aspects apply to all its subclasses.
Contextual dependency injection: resolve different implementations of the same interface in different situations. The context can be static, as with Laravel’s contextual bindings, but Canvas also lets you compute it per request, declared directly on the annotation.
ObjectQuel: a QUEL-inspired query language instead of DQL. Relationships are traversed with via, and queries that outgrow DQL, such as window functions or recursive traversal, stay in the language instead of dropping to raw SQL.
I designed it this way because I think explicit structure, clear boundaries between responsibilities, and endpoint behavior that is easy to discover make a codebase easier to work in.
I’ve also written a technical comparison with Laravel and Symfony covering routing, dependency injection, persistence, and the trade-offs involved.
If you find it interesting, I'd be happy to hear your thoughts.
https://redd.it/1xj96xn
@r_php
PHP жив?
/r/RuProgrammers/comments/1xipwl8/php_жив/
https://redd.it/1xipwt3
@r_php
This Week In PHP Internals | Oct 29, 2026
https://youtube.com/watch?v=oeDHs-qXXwA&si=5ba8u5NnilpJ3_aX
https://redd.it/1xix3qk
@r_php
I open-sourced chatVia.ai, a self-hosted RAG chat platform built on Laravel 13
/r/laravel/comments/1xiqa8j/i_opensourced_chatviaai_a_selfhosted_rag_chat/
https://redd.it/1xiqafc
@r_php
Framework for creating PHP extension using the Zig language
https://github.com/chung-leong/zig-php-ext
https://redd.it/1xiotlu
@r_php
SymfonyCon Warsaw 2026: Symfony Mate: From Hallway Idea to Daily Driver
https://symfony.com/blog/symfonycon-warsaw-2026-symfony-mate-from-hallway-idea-to-daily-driver?utm_source=Symfony%20Blog%20Feed&utm_medium=feed
https://redd.it/1xim525
@r_php
Chained PHP2Shell Exploit Roots 25 Servers
https://dreamgroup.com/blog/chained-php2shell-exploit-roots-25-servers
https://redd.it/1xiji7a
@r_php
One week after the PHP2Shell fix: about half of live sites on 8.2–8.5 show a patched release, and under 1% on 5.4–7.3 have moved. How we counted
I work at IPinfo, where we scan the IPv4 and IPv6 Internet. On October 22, the day after the fixed releases (8.5.12, 8.4.27, 8.3.36, 8.2.35), we started re-checking the same 1.46 million addresses that show a PHP version every day.
**Where they started.** In our October 14–15 scan, 1,105,160 addresses showed a PHP version. 409,494 of them (37%) ran 5.4–7.3, which is affected and gets no free official fix.
**One week later.** Of the servers that weren’t yet on a patched release on October 22:
* Live sites on 8.2–8.5: 36.5% patched on day one, 47.5% by October 28 (41,707 of 87,865). Almost everything happened on the first day.
* Default pages, panels and devices on 8.2–8.5: 23.0%.
* Live sites on 5.4–7.3: 0.95% moved to a patched release (1,249 of 131,024).
Among servers still showing a vulnerable version, 47% now run 7.3 or older. For comparison, Wiz reported 5.7% for its customers’ cloud machines. The open Internet has a much longer tail.
**How we counted:**
* Patched means the version string shows 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or later, lowest version per address.
* We left out addresses that show PHP only on hosting control-panel ports (2082, 2083, 2086, 2087, 2095, 2096), and blocks where 64 or more addresses in a /24 (or /64) send the identical response. That’s one machine answering for many.
* “Live site” means the page looked like a site in use in our October 14–15 scan, not a default page, login panel or device.
* We dropped October 26 from the series. One large host’s proxy hid PHP versions on tens of thousands of servers for that day only.
**Caveats:**
* Some hosts (GoDaddy, cPanel’s EasyApache packages) and distributions backport fixes without changing the version number, and TuxCare sells patched builds for 5.x–8.1. So these numbers are minimums.
* We measure versions, not break-ins. CISA added PHP2Shell to its known-exploited list on October 26, but we can’t see who was attacked.
Happy to answer questions on the method. I write these up in a short brief: [https://ipinfo.io/blog/internet-brief-1?utm\_source=reddit\_r\_php&utm\_medium=social&utm\_campaign=php2shell](https://ipinfo.io/blog/internet-brief-1?utm_source=reddit_r_php&utm_medium=social&utm_campaign=php2shell)
https://redd.it/1xiiql9
@r_php
New in Symfony 8.2: Cross-Application Messaging
https://symfony.com/blog/new-in-symfony-8-2-cross-application-messaging?utm_source=Symfony%20Blog%20Feed&utm_medium=feed
https://redd.it/1xigp8u
@r_php
phpwarden — open-source scanner for PHP engine, composer.lock and WordPress CVEs, ranked by what's actually being exploited (KEV + EPSS)
https://github.com/primeagent001-bot/phpwarden
https://redd.it/1xhnbwy
@r_php