CVE-2025-53521

F5 BIG-IP Stack-Based Buffer Overflow Exploitation (CVE-2025-53521)

Detects exploitation attempts and post-exploitation activity related to CVE-2025-53521, a stack-based buffer overflow vulnerability (CWE-121) in F5 BIG-IP. This vulnerability is listed in CISA's Known Exploited Vulnerabilities catalog and may allow remote attackers to execute arbitrary code or cause denial of service by sending crafted requests that overflow stack buffers in BIG-IP processing components.

Vulnerability Intelligence

KEV — Known Exploited

CVSS

9.8
Critical (9.0–10)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Write-up coming soon

What is CVE-2025-53521 F5 BIG-IP Stack-Based Buffer Overflow Exploitation (CVE-2025-53521)?

F5 BIG-IP Stack-Based Buffer Overflow Exploitation (CVE-2025-53521) (CVE-2025-53521) maps to the Initial Access and Execution and Lateral Movement tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for F5 BIG-IP Stack-Based Buffer Overflow Exploitation (CVE-2025-53521), covering the data sources and telemetry it touches: CommonSecurityLog, DeviceNetworkEvents, Syslog. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Execution Lateral Movement
Microsoft Sentinel / Defender
kusto
union CommonSecurityLog, DeviceNetworkEvents
| where TimeGenerated >= ago(24h)
| where DeviceVendor == "F5" or DeviceProduct has "BIG-IP"
| where Activity has_any ("overflow", "stack", "segfault", "crash", "core dump") or Message has_any ("buffer overflow", "stack smash", "segmentation fault", "tmm crash", "mcpd crash")
| extend RequestSize = toint(AdditionalExtensions)
| where RequestSize > 65535 or isnotempty(RequestSize) and RequestSize < 0
| project TimeGenerated, DeviceVendor, DeviceProduct, SourceIP, DestinationIP, DestinationPort, Activity, Message, LogSeverity
| union (
    CommonSecurityLog
    | where TimeGenerated >= ago(24h)
    | where DeviceProduct has "BIG-IP"
    | where LogSeverity in ("Emergency", "Alert", "Critical")
    | where Message has_any ("CVE-2025-53521", "K000156741", "K000160486", "stack overflow", "buffer overflow")
    | project TimeGenerated, DeviceVendor, DeviceProduct, SourceIP, DestinationIP, DestinationPort, Activity, Message, LogSeverity
)
| order by TimeGenerated desc

Detects F5 BIG-IP buffer overflow exploitation via CommonSecurityLog and DeviceNetworkEvents, looking for crash signals, oversized payloads, and critical severity events referencing stack/buffer overflow conditions.

critical severity medium confidence

Data Sources

CommonSecurityLog DeviceNetworkEvents Syslog

Required Tables

CommonSecurityLog DeviceNetworkEvents

False Positives

  • Legitimate high-volume traffic from load testing tools that may trigger oversized payload alerts
  • BIG-IP software bugs or hardware faults causing unrelated crash logs with similar keywords
  • Security scanners performing vulnerability assessments against BIG-IP devices
  • Misconfigured applications sending malformed but benign requests to BIG-IP virtual servers

Sigma rule & cross-platform mapping

The detection logic for F5 BIG-IP Stack-Based Buffer Overflow Exploitation (CVE-2025-53521) (CVE-2025-53521) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Oversized HTTP POST Payload to BIG-IP Virtual Server

    Expected signal: Network flow logs showing source IP sending >65535 bytes to BIG-IP destination port. BIG-IP LTM logs showing oversized request from test source IP. Possible 400 Bad Request or connection reset depending on BIG-IP version.

  2. Test 2BIG-IP iControl REST Reconnaissance Prior to Exploitation

    Expected signal: BIG-IP iControl REST access logs in `/var/log/restjavad.0.log` showing authenticated GET requests from test source IP. Network logs showing HTTPS connections to BIG-IP management IP on port 443.

  3. Test 3Simulate BIG-IP TMM Crash and Core Dump Generation

    Expected signal: Syslog messages from BIG-IP host containing 'tmm' process restart events, critical severity entries, and potential core dump references in `/var/core/`. F5 SNMP traps if configured.


Response Playbook

Triage

  1. Identify the affected F5 BIG-IP device(s) by correlating source/destination IPs in alerts with your BIG-IP asset inventory. Confirm the device model and software version via TMSH: `tmsh show sys version`.
  2. Review BIG-IP system logs for crash indicators: check `/var/log/tmm`, `/var/log/ltm`, and `/var/log/mcpd` for segmentation faults, core dumps, or stack overflow messages occurring near the alert timestamp.
  3. Inspect inbound traffic logs for anomalous request sizes or malformed payloads targeting BIG-IP virtual server IPs around the time of the alert, focusing on ports 443, 80, 4353, and any custom virtual server ports.
  4. Check CISA KEV and F5 advisory K000156741 to confirm whether your BIG-IP version falls within the affected range and whether the patch has been applied.

Containment

  1. If active exploitation is confirmed or strongly suspected, immediately isolate the affected BIG-IP device from the network by placing it in maintenance mode or disabling affected virtual servers: `tmsh modify ltm virtual <vs-name> disabled`.
  2. Apply F5 iRule-based mitigations or BIG-IP ASM/WAF policies to block or rate-limit oversized payloads to affected virtual servers as an interim measure while patching is coordinated.
  3. Block identified attacker source IPs at upstream network controls (firewall, upstream router ACL) to prevent continued exploitation attempts.

Evidence Collection

  1. Capture core dump files from `/var/core/` on the affected BIG-IP for forensic analysis. Preserve timestamps and do not modify files in place.
  2. Export BIG-IP qkview (`qkview -f /var/tmp/incident-$(date +%Y%m%d).qkview`) for F5 TAC and internal forensics, which bundles logs, configuration, and system state.

Escalation Criteria

  • ! Escalate immediately to the security incident response team and F5 TAC if core dumps, shell access from unexpected processes, or lateral movement from the BIG-IP management IP are observed post-exploitation.
  • ! Escalate to executive leadership and legal/compliance if the BIG-IP device handles PCI, HIPAA, or other regulated traffic and active exploitation is confirmed, triggering breach notification assessment.

Investigation Guide

Forensic Artifacts

  • > Core dump files at `/var/core/` on BIG-IP filesystems containing stack memory at time of crash
  • > BIG-IP LTM and TMM logs at `/var/log/ltm` and `/var/log/tmm` containing crash timestamps and source IPs
  • > iControl REST API access logs at `/var/log/restjavad.0.log` for any unauthorized management API calls following exploitation
  • > Network packet captures from BIG-IP span port or upstream TAP showing the malformed request payload triggering the overflow

Tuning Guidance

Start by scoping alerts to confirmed BIG-IP asset IPs in your environment to reduce noise from unrelated F5 vendor log sources. Tune the payload size threshold (default 65535 bytes) based on your largest legitimate application transfer sizes — increase to 131072 for environments handling large file uploads. For crash signal detection, add specific process names (tmm, mcpd) to reduce false positives from application-layer logs. If your BIG-IP is already patched per F5 advisory K000156741, consider demoting severity to informational and keeping the rule active for detection of unpatched systems in shadow IT.


Hunting Queries

Hunt for BIG-IP devices generating clusters of critical severity events over the past 7 days, which may indicate repeated exploitation attempts or crash loops resulting from CVE-2025-53521 abuse.

Hunting — KQL
kql
CommonSecurityLog
| where TimeGenerated >= ago(7d)
| where DeviceVendor == "F5" or DeviceProduct has "BIG-IP"
| where LogSeverity in ("0", "1", "2") // Emergency, Alert, Critical
| summarize CrashCount=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), SourceIPs=make_set(SourceIP) by DeviceName, bin(TimeGenerated, 1h)
| where CrashCount > 3
| order by CrashCount desc
Hunting — SPL
spl
index=f5 sourcetype="f5:bigip:syslog" severity IN ("emerg", "alert", "crit") earliest=-7d
| bucket _time span=1h
| stats count as crash_count values(src_ip) as source_ips by host, _time
| where crash_count > 3
| sort - crash_count

Atomic Red Team Tests

Test 1 Oversized HTTP POST Payload to BIG-IP Virtual Server
linux

Sends an oversized HTTP POST request to a BIG-IP virtual server to simulate the payload size condition associated with stack buffer overflow exploitation. Use only against lab/test BIG-IP instances with explicit authorization.

Command

bash
python3 -c "
import socket, random, string
host = '${TARGET_BIGIP_IP}'
port = 443
payload_size = 131072
payload = ''.join(random.choices(string.ascii_letters, k=payload_size))
request = f'POST /vulnerable-endpoint HTTP/1.1\\r\\nHost: {host}\\r\\nContent-Length: {payload_size}\\r\\nContent-Type: application/octet-stream\\r\\n\\r\\n{payload}'
try:
    s = socket.create_connection((host, port), timeout=10)
    s.send(request.encode())
    resp = s.recv(4096)
    print(resp.decode(errors='ignore'))
    s.close()
except Exception as e:
    print(f'Connection result: {e}')
"

Cleanup

bash
No cleanup required. Connection is closed after single request. Monitor BIG-IP `/var/log/ltm` for generated log entries and delete test-generated traffic logs if required by lab policy.

Expected Telemetry

Network flow logs showing source IP sending >65535 bytes to BIG-IP destination port. BIG-IP LTM logs showing oversized request from test source IP. Possible 400 Bad Request or connection reset depending on BIG-IP version.

Expected Detection

KQL and SPL queries should fire on the oversized payload condition. If BIG-IP is vulnerable, a tmm crash may be visible in `/var/log/tmm` and a core dump generated in `/var/core/`.

Test 2 BIG-IP iControl REST Reconnaissance Prior to Exploitation
linux

Simulates attacker reconnaissance of the BIG-IP iControl REST API to enumerate version and virtual server configuration before targeting CVE-2025-53521. Lab use only.

Command

bash
curl -sk -u 'admin:${BIGIP_ADMIN_PASS}' 'https://${TARGET_BIGIP_IP}/mgmt/tm/sys/version' | python3 -m json.tool && curl -sk -u 'admin:${BIGIP_ADMIN_PASS}' 'https://${TARGET_BIGIP_IP}/mgmt/tm/ltm/virtual' | python3 -m json.tool

Cleanup

bash
Review `/var/log/restjavad.0.log` on BIG-IP to confirm test log entries. No configuration changes made; no cleanup required beyond log review.

Expected Telemetry

BIG-IP iControl REST access logs in `/var/log/restjavad.0.log` showing authenticated GET requests from test source IP. Network logs showing HTTPS connections to BIG-IP management IP on port 443.

Expected Detection

Hunting queries monitoring iControl REST access from non-whitelisted IPs or outside business hours should surface this activity. SIEM alerts on BIG-IP management API access from new source IPs.

Test 3 Simulate BIG-IP TMM Crash and Core Dump Generation
linux

On a lab BIG-IP instance, manually triggers a non-destructive TMM restart to simulate crash telemetry that would be generated post-exploitation. Validates that crash log detection rules are working correctly.

Command

bash
ssh -p 22 admin@${TARGET_BIGIP_IP} 'tmsh restart sys service tmm && sleep 5 && tail -50 /var/log/tmm | grep -E "(crash|segfault|core|restart|overflow)"'

Cleanup

bash
TMM will automatically restart. Verify BIG-IP is operational after test: `tmsh show sys service tmm`. Remove test SSH session logs from BIG-IP audit log if required: review `/var/log/audit`.

Expected Telemetry

Syslog messages from BIG-IP host containing 'tmm' process restart events, critical severity entries, and potential core dump references in `/var/core/`. F5 SNMP traps if configured.

Expected Detection

SIEM crash signal detection rules (SPL, KQL) should alert on critical-severity syslog entries referencing tmm process events. Chronicle and QRadar rules should surface F5 vendor log entries with crash keywords.

Related Detections