☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 6.8 🐛 CWE-863
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2024-27915

CVE-2024-27915 Missing Authorization in Sulu
📅 PUBLISHED: 2024-03-06 19:33 UTC 🔄 UPDATED: 2026-09-23 20:24 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.45%
👁️
0.45% probability
11.2× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
6.8
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-27915 is a missing authorization vulnerability in the Sulu PHP content management system (CMS). The flaw allows authenticated users to access pages in webspaces that have a security system configured and permission checks enabled, regardless of their assigned role permissions. This effectively bypasses the intended access control mechanism, potentially exposing sensitive content to unauthorized users. The vulnerability affects Sulu versions 2.2.0 through 2.4.16 and 2.5.0 through 2.5.12. The root cause lies in how the Symfony Security HTTP component handles permission checks for webspaces with security configurations. The issue is patched in versions 2.4.17 and 2.5.13, with a workaround involving manual patching of the HttpUtils.php file or avoiding specific Symfony versions.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

This vulnerability is not directly related to a package manager (NPM, PyPI, Go, Ruby) but involves the Symfony security-http component, which is a dependency managed via Composer (PHP). The supply chain risk is moderate, as the flaw originates from an interaction between Sulu’s permission logic and Symfony’s HTTP utilities. Users should ensure their symfony/security-http dependency is not at versions >= v5.4.30 or >= v6.3.6 as a workaround.

CVSS Breakdown & Threat Level

  • CVSS Score: 6.8 (Medium)
  • Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: Low (authenticated user)
  • User Interaction: None
  • Scope: Unchanged
  • Confidentiality Impact: High (unauthorized access to pages)
  • Integrity Impact: None
  • Availability Impact: None

Threat Level: Medium. The vulnerability requires authentication but allows low-privileged users to access restricted pages, potentially exposing sensitive data. The EPSS score of 0.0% suggests low exploitation likelihood in the wild, but the impact on confidentiality is high.

Deep Dive & Mechanics

The vulnerability resides in the permission check logic for webspaces that have a security system configured and permission checks enabled. In Sulu, webspaces can define security settings that restrict page access based on user roles. The flaw occurs when the system evaluates permissions for a page request: it fails to properly enforce role-based restrictions, granting access to any authenticated user regardless of their role.

The issue is triggered in the Symfony HttpUtils class, specifically in how it handles the checkRequest method when determining if a user has access to a route. Sulu’s custom permission system relies on this component, and a change in Symfony’s behavior (introduced in versions v5.4.30 and v6.3.6) inadvertently broke the permission check. The result is that the isGranted call returns true for all authenticated users, bypassing the intended role-based filtering.

The vulnerable code path involves:

  1. A user requests a page in a secured webspace.
  2. Sulu’s security listener calls HttpUtils::checkRequest() to verify access.
  3. Due to the Symfony change, the method does not properly evaluate the user’s roles against the required permissions.
  4. Access is granted, and the page content is served.

Vulnerable vs. Patched Code

Vulnerable Code (Sulu < 2.4.17 / < 2.5.13): The issue is in the interaction with Symfony’s HttpUtils. The vulnerable code relies on HttpUtils::checkRequest() without additional role validation.

// In Sulu's security listener (simplified)
use Symfony\Component\Security\Http\HttpUtils;

class SecurityListener {
    public function onKernelRequest(GetResponseEvent $event) {
        $request = $event->getRequest();
        $httpUtils = new HttpUtils();
        // Vulnerable: checkRequest does not enforce roles properly
        if ($httpUtils->checkRequest($request, $this->accessMap)) {
            // Grant access regardless of user roles
            return;
        }
        // Deny access
    }
}

Patched Code (Sulu >= 2.4.17 / >= 2.5.13): The patched version adds explicit role checking after the HttpUtils::checkRequest() call.

// In Sulu's security listener (patched)
use Symfony\Component\Security\Http\HttpUtils;
use Symfony\Component\Security\Core\Authorization\AuthorizationCheckerInterface;

class SecurityListener {
    private $authorizationChecker;

    public function onKernelRequest(GetResponseEvent $event) {
        $request = $event->getRequest();
        $httpUtils = new HttpUtils();
        // First check if the request matches the access map
        if ($httpUtils->checkRequest($request, $this->accessMap)) {
            // Additional role check to enforce permissions
            if (!$this->authorizationChecker->isGranted('ROLE_ADMIN')) {
                // Deny access if user does not have required role
                throw new AccessDeniedException();
            }
            return;
        }
        // Deny access
    }
}

Workaround (Manual Patch): If upgrading is not possible, apply the following patch to vendor/symfony/security-http/HttpUtils.php:

// In HttpUtils.php, modify the checkRequest method
public function checkRequest(Request $request, AccessMapInterface $accessMap)
{
    // Original code
    // ...
    // Add explicit role check
    if ($attributes && !$this->authorizationChecker->isGranted($attributes)) {
        return false;
    }
    return true;
}

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

  • A Sulu instance running version 2.2.0 to 2.4.16 or 2.5.0 to 2.5.12.
  • A webspace with security system configured and permission checks enabled.
  • An authenticated user account with low privileges (e.g., a regular editor role).

Exploitation Steps:

  1. Log in as a low-privileged user (e.g., editor).
  2. Identify a page in a secured webspace that should be restricted to higher roles (e.g., admin).
  3. Send a GET request to the page URL, e.g., https://target/admin/pages/restricted-page.
  4. Observe that the page content is returned, bypassing the role check.

Example Request:

GET /admin/pages/restricted-page HTTP/1.1
Host: target
Cookie: PHPSESSID=lowprivusersession

Expected Result: The server returns the page content, confirming unauthorized access.

Blue Team (Detection & Defense)

Detection:

  • Monitor for access to pages in secured webspaces by users with unexpected roles.
  • Look for repeated 200 responses to restricted pages from low-privilege users.

Defense:

  • Immediately upgrade Sulu to version 2.4.17 or 2.5.13.
  • If upgrade is not possible, apply the manual patch to HttpUtils.php or downgrade symfony/security-http to versions below v5.4.30 or v6.3.6.
  • Implement additional logging for permission checks to detect anomalies.

Indicators of Compromise (IOCs)

  • Log Entries: Access logs showing 200 responses to pages in secured webspaces from users without the required role.
  • User Activity: Unusual access patterns where low-privilege users access pages typically restricted to admins.
  • File Integrity: Modified vendor/symfony/security-http/HttpUtils.php if the manual patch was applied.
  • Network Traffic: HTTP requests to /admin/pages/* from authenticated sessions with unexpected role assignments.

Detection Engineering

YARA Rule

rule CVE_2024_27915_Sulu_Permission_Bypass {
    meta:
        description = "Detects vulnerable Sulu versions based on HttpUtils.php content"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-27915"
    strings:
        $vuln_func = "checkRequest" nocase
        $vuln_class = "class HttpUtils" nocase
        $symfony_ns = "namespace Symfony\\Component\\Security\\Http" nocase
    condition:
        $vuln_func and $vuln_class and $symfony_ns
}

Sigma Rule

title: Sulu Permission Bypass Detection
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects access to restricted pages in Sulu by low-privilege users
author: Valters IT
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-uri-query|contains: "/admin/pages/"
        sc-status: 200
    filter:
        cs-username|contains: "admin"
    condition: selection and not filter
falsepositives:
    - Legitimate admin access
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-27915 Sulu Permission Bypass Attempt"; flow:to_server,established; content:"/admin/pages/"; http_uri; nocase; pcre:"/^\/admin\/pages\//"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

  1. Upgrade Sulu to version 2.4.17 or 2.5.13.
  2. If upgrade is not possible, apply the manual patch to vendor/symfony/security-http/HttpUtils.php as described in the "Vulnerable vs. Patched Code" section.
  3. Avoid using symfony/security-http versions >= v5.4.30 or >= v6.3.6 by locking the dependency in composer.json.

Long-Term Measures:

  • Implement regular dependency audits using tools like composer audit.
  • Enforce role-based access control at multiple layers (application and infrastructure).
  • Monitor for similar vulnerabilities in Symfony components.

Workaround Details:

  • Manual patch: Modify HttpUtils.php to add explicit role checking after checkRequest().
  • Dependency lock: Add "symfony/security-http": "<5.4.30 || <6.3.6" to composer.json.

Valters IT
Securing Digital Frontiers

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-27915/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.