CVE-2026-54544

Executive Summary

CVE-2026-54544 is a server-side request forgery (SSRF) vulnerability (CWE-918) in Fireshare, a self-hosted media and link-sharing application. Prior to version 1.6.16, two API endpoints — POST /api/test-discord-webhook and POST /api/test-webhook — lack the @login_required decorator, allowing any unauthenticated attacker to force the server to issue arbitrary HTTP POST requests to attacker-controlled URLs, including internal services and cloud metadata endpoints. With no credentials or session required and a CVSS v3.1 base score of 7.2, this represents a remotely exploitable, network-accessible flaw whose primary impact is internal network reconnaissance and metadata credential theft.

Technical Analysis

Fireshare is a Python-based self-hosted application (typically deployed via Docker) enabling users to share media and links. The vulnerability class here is Server-Side Request Forgery (SSRF), mapped to CWE-918. The NVD description states that two endpoints intended to trigger outbound HTTP requests are missing their authentication guard.

Normally, webhook "test" endpoints are administrative or user-authenticated features: an operator supplies a webhook URL, and the server sends a synthetic POST to validate connectivity. In Fireshare before 1.6.16, the @login_required decorator — a standard Flask-like authorization guard — was omitted on two such routes:

• POST /api/test-discord-webhook
• POST /api/test-webhook

Because these routes are unauthenticated, an attacker with network reach to the Fireshare instance can supply an arbitrary destination URL. The application then performs an outbound HTTP POST from the server's network context. The security impact is a direct consequence of the confused deputy problem: the Fireshare server, which likely has access to internal networks, cloud instance metadata services, or privileged corporate segments, is coerced into acting as the attacker's request proxy.

The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:L is analytically consistent with the description:

• AV:N — reachable over the network.
• AC:L — no special conditions; tooling suffices.
• PR:N — no authentication required (the crux of the flaw).
• UI:N — no victim interaction; the attacker directly invokes the endpoint.
• S:C — scope is changed: the vulnerable Fireshare component is used to impact resources in other security scopes (internal networks, cloud metadata).
• C:L / I:L / A:L — limited confidentiality, integrity, and availability impact. The POST body is attacker-controlled (integrity of the target service is influenced), responses may leak internal information, and request flooding or triggering state-changing internal endpoints can cause limited availability effects.

Notably, the absence of C/I/A "High" ratings reflects that the primary guarantee is reachability rather than direct data exfiltration: the attacker can cause requests but the response handling determines whether data is returned to them.

Exploitation Scenarios

The attack chain is inferred from the vulnerability class and the explicit endpoint names and behavior given in the NVD description. No public PoC is available.

1. Reconnaissance / Target Identification. An attacker enumerates internet-exposed Fireshare instances (e.g., via Shodan using http.html:"Fireshare" or the favicon hash). Any reachable instance running a version below 1.6.16 is a candidate. No credentials are needed.

2. Triggering the Flaw. The attacker sends a direct HTTP POST to one of the unauthenticated endpoints — POST /api/test-discord-webhook or POST /api/test-webhook — with a JSON/form parameter specifying an attacker-chosen destination URL. Because @login_required is absent, the request is processed without any authentication check.

3. Payload / Execution (vulnerability-class level). The Fireshare server deconstructs the supplied URL and issues its own outbound HTTP POST to that destination. The attacker targets:

   • Cloud metadata services (e.g., the link-local metadata IP) to extract instance credentials/tokens, potentially enabling lateral movement into the cloud account.
   • Internal network addresses (localhost, RFC1918 ranges) hosting admin panels, internal APIs, or databases to enumerate/confirm reachable services — a classic SSRF port/service-scan and reconnaissance primitive.
   • Attacker-controlled external hosts to confirm the SSRF and observe the Fireshare server's outbound source IP, User-Agent, and timing.

   Because the method is a POST (not GET), attacker-supplied request content can reach state-changing internal endpoints — e.g., internal REST APIs that act on POST bodies.

4. Post-Exploitation Impact. Successful SSRF yields internal network reconnaissance, potential access to cloud metadata credentials (which may be replayable to cloud APIs), and the ability to interact with internal services as the Fireshare host. While the description does not confirm that response bodies are reflected to the attacker, the server-side reach alone constitutes a significant foothold. Availability impact is limited but present via request amplification against internal targets.

Impact Assessment

• Business Impact: Self-hosted Fireshare deployments, especially in cloud (AWS/GCP/Azure) environments, expose a well-known attack pattern (SSRF to metadata) that can lead to credential theft and full cloud-account compromise. Internal network reconnaissance enables follow-on lateral movement.
• Affected Systems: Fireshare instances below 1.6.16 that are network-reachable by untrusted parties. Internet-facing instances are highest risk; internal-network instances are still vulnerable to insider/lateral attackers.
• Blast Radius: Scope is Changed (S:C) — the vulnerable component indirectly affects resources outside its own trust boundary. The confidentiality, integrity, and availability impacts are each "Limited" (C:L/I:L/A:L), so the parent application itself is not directly destroyed, but downstream internal/cloud targets are placed at risk.
• Exploitability: CVSS AV:N/AC:L/PR:N/UI:N makes this trivially exploitable in principle. EPSS 0.00320 (~25th percentile) indicates current exploitation likelihood is low, consistent with no public PoC, no Nuclei template, and no exploit code being observed.

Detection Guidance

Sigma Rule

title: Fireshare Unauthenticated SSRF via Webhook Test Endpoints
id: 8f3a2c1e-5b6d-4e7f-9a10-2c3d4e5f6a7b
status: experimental
description: Detects unauthenticated POST requests to Fireshare webhook test endpoints that can trigger server-side request forgery (CVE-2026-54544).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-54544
author: valtersit.com
date: 2026-01-01
logsource:
  category: webserver
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem:
      - '/api/test-webhook'
      - '/api/test-discord-webhook'
  condition: selection
fields:
  - c-ip
  - cs-uri-stem
  - cs-method
falsepositives:
  - Legitimate authenticated administrators testing webhooks
level: high
tags:
  - attack.t1190
  - cve.2026.54544
  - cwe.918

YARA Rule

rule CVE_2026_54544_Fireshare_SSRF
{
    meta:
        author = "valtersit.com"
        description = "Detects code patterns associated with missing @login_required on Fireshare webhook test endpoints (CVE-2026-54544)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-54544"
        date = "2026-01-01"
        severity = "high"
    strings:
        $route1 = "/api/test-webhook"
        $route2 = "/api/test-discord-webhook"
        $decorator = "@login_required"
        $post = "POST"
        $banner = "Fireshare"
    condition:
        $banner and ($route1 or $route2) and not $decorator
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-54544 Fireshare Unauthenticated SSRF Webhook Test Endpoint"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/api/test-"; http.uri; content:"webhook"; nocase; classtype:web-application-attack; reference:cve,2026-54544; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-54544; sid:202654544; rev:1;)

Elastic Detection

sequence by process.entity_id
  [process where event.action == "start" and process.name : ("python", "python3") and process.args : "*test-webhook*"]
  [network where event.type == "start" and destination.ip != null]

Splunk SPL Query

index=web sourcetype=access_common
| search (uri_path="/api/test-webhook" OR uri_path="/api/test-discord-webhook") method=POST
| stats count, values(src_ip) as src_ips, values(user_agent) as user_agents by uri_path
| where count > 0
| table uri_path, count, src_ips, user_agents

Wazuh OSSEC Rule

<group name="web,fireShare,ssrf,">
  <rule id="100544" level="12">
    <decoded_as>json</decoded_as>
    <field name="url">\/api\/test-(discord-)?webhook</field>
    <same_field>method</same_field>
    <field name="method">POST</field>
    <description>CVE-2026-54544: Possible unauthenticated SSRF attempt against Fireshare webhook test endpoint</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve_2026_54544,ssrf,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch (not independently confirmed)). The OSV source claims version 1.6.16 contains the fix, but this has not been independently confirmed. Affected version range and OSV package data are incomplete/empty.

1. Immediate Mitigations (apply before patching if possible):

   • Block external/untrusted network access to the Fireshare instance (reverse proxy ACLs, firewall rules) until upgraded.
   • At the reverse proxy (e.g., nginx), deny or require authentication for POST /api/test-webhook and POST /api/test-discord-webhook.
   • Add egress filtering (network policy / firewall) so the Fireshare host cannot reach the cloud metadata endpoint (block the link-local metadata IP) or unrestricted internal ranges. This directly neutralizes the SSRF's most damaging payloads even without a code fix.
   • Enforce IMDSv2 / metadata-access hardening on cloud hosts where possible.

2. Patch / Upgrade Steps:

   • Upgrade Fireshare to version 1.6.16 or later, which adds the @login_required decorator to the affected endpoints (per the single-source claim).
   • Because patch confidence is only 2/4, verify the decorator is present on both endpoints after upgrade (inspect the route definitions or test unauthenticated access) rather than assuming.
   • Confirm the running container image tag reflects ≥ 1.6.16 and redeploy.

3. Long-Term Hardening:

   • Treat all webhook/URL-fetch features as SSRF-prone; require authentication and enforce a destination allowlist / denylist for outbound requests.
   • Deploy a network-layer egress policy (deny-by-default) for application containers.
   • Add automated dependency/version monitoring to catch regressions that reintroduce missing authorization decorators.
   • Integrate the Sigma/Suricata detections above into the SOC to flag unauthenticated hits to these endpoints.

References

• NVD — CVE-2026-54544: https://nvd.nist.gov/vuln/detail/CVE-2026-54544
• Fireshare project repository / release 1.6.16 (official source for the patch; verify independently): https://github.com/ShaneIsrael/fireshare
• CWE-918 — Server-Side Request Forgery (SSRF): https://cwe.mitre.org/data/definitions/918.html
• OWASP — Server Side Request Forgery: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
• OSV advisory entry (single-source patch claim for 1.6.16): https://osv.dev/

Threat Actor / Exploit-in-the-Wild Status: No evidence of active exploitation. CISA KEV: NO. EPSS: 0.00320 (~25th percentile). No public PoC, no Nuclei template, and no exploit code are currently available, indicating exploitation has not yet been observed in the wild.