Listen to this Post
How CVE-2026-49209 Works
Symfony UX Live Component allows developers to build real‑time interactive Twig components that update without full page reloads. One of its core features is batch action processing, exposed via the `/ _components/{component}/_batch` endpoint. When a client sends a `_batch` request, the server-side `BatchActionController::__invoke()` method receives an array of actions supplied by the user.
The controller then iterates over this client‑controlled `actions` array and, for each entry, spawns a full `HttpKernel` sub‑request. Every sub‑request triggers the entire Symfony request lifecycle: event subscribers are dispatched, validation constraints are executed, Doctrine ORM flushes database changes, Twig templates are rendered, and all associated services are bootstrapped. This is extremely resource‑intensive even for a single action.
Critically, the original implementation placed no upper bound on the number of actions that could be submitted in one batch. An authenticated attacker could therefore craft a single `_batch` payload containing thousands (or even tens of thousands) of action entries. Upon receiving such a request, the server would dutifully execute each action as a separate sub‑request, consuming CPU time, exhausting memory, and saturating database connection pools. Because the processing is synchronous, the HTTP response is only sent after all actions complete, leading to prolonged request handling and rendering the application unresponsive to other legitimate traffic.
The vulnerability is particularly dangerous because it does not require any special privileges beyond standard authentication – any logged‑in user with access to a Live Component endpoint can mount the attack. The issue affects all versions from 2.5.0 up to (but not including) 2.36.0, and from 3.0.0 up to (but not including) 3.1.0. The Symfony security team addressed the problem by introducing a hard limit of 50 actions per `_batch` request (MAX_ACTIONS_PER_BATCH). Any payload exceeding this threshold is rejected immediately with a BadRequestHttpException, preventing the server from ever entering the expensive sub‑request loop. The JavaScript frontend was also updated to split larger client‑side batches into multiple smaller requests, ensuring that legitimate multi‑action use cases remain functional without degrading performance.
DailyCVE Form
Platform: …… Symfony UX Live Component
Version: …….. 2.5.0–2.35.0, 3.0.0–3.0.0
Vulnerability :.. Unbounded resource consumption (DoS)
Severity: ……. Low
date: ……….. 2026‑05‑29
Prediction: ….. Patch available 2026‑05‑29
What Undercode Say
Simulate a DoS attack by submitting 1000 actions in one _batch request
curl -X POST https://target.example.com/_components/MyComponent/_batch \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{
"actions": [
{"name": "doSomething", "args": {}},
{"name": "doSomething", "args": {}},
... (repeat 1000 times) ...
]
}'
// Before patch (vulnerable) – BatchActionController::__invoke()
public function __invoke(Request $request): JsonResponse
{
$actions = $request->toArray()['actions'] ?? [];
foreach ($actions as $action) {
// No limit – each triggers a full HttpKernel sub‑request
$this->handleAction($action);
}
// ...
}
// After patch (fixed) – introduces MAX_ACTIONS_PER_BATCH = 50
public function __invoke(Request $request): JsonResponse
{
$actions = $request->toArray()['actions'] ?? [];
if (count($actions) > self::MAX_ACTIONS_PER_BATCH) {
throw new BadRequestHttpException(
sprintf('Maximum %d actions per batch allowed.', self::MAX_ACTIONS_PER_BATCH)
);
}
foreach ($actions as $action) {
$this->handleAction($action);
}
// ...
}
Exploit
An authenticated attacker sends a `POST` request to `/_components/{component}/_batch` with a JSON payload containing an `actions` array of 1,000 or more entries. Each entry calls a valid `[bash]` method (e.g., a no‑op or a simple state update). Because the server processes every action as a separate sub‑request, the application enters a resource‑intensive loop that can:
– Saturate all available CPU cores.
– Exhaust PHP memory limits.
– Fill database connection pools with idle or active connections.
– Delay the HTTP response until all actions finish, causing timeouts.
The attack can be repeated with varying batch sizes to maintain constant high load, effectively rendering the application unavailable to other users.
Protection
- Upgrade `symfony/ux-live-component` to 2.36.0 or 3.1.0 (or later). These versions enforce the 50‑action limit and reject oversized batches upfront.
- If an immediate upgrade is not possible, apply the patch from the Symfony repository that adds the `MAX_ACTIONS_PER_BATCH` check to
BatchActionController::__invoke(). - As a temporary workaround, place a reverse proxy or API gateway in front of the application that validates the `actions` array size and rejects requests with more than 50 entries before they reach Symfony.
- Monitor server resource usage and set up alerts for unusual spikes in `_batch` request volumes.
Impact
- Resource Exhaustion: Unauthenticated (or authenticated) clients can cause CPU, memory, and database connection exhaustion, leading to denial of service.
- Application Downtime: Prolonged request processing blocks the event loop, making the application unresponsive to legitimate users.
- No Data Breach: The vulnerability is limited to availability; it does not expose or corrupt data.
- Low Severity: The attack requires authentication and the impact is primarily operational, hence the Low severity rating assigned by Symfony.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
