Vulnerability Watch

What Lantronix EDS5000 is: A serial-to-IP converter — a piece of hardware that connects older serial devices (like industrial sensors or legacy equipment) to a modern network, often found in factories, hospitals, and infrastructure environments.

What it is: This flaw allows an attacker to inject arbitrary operating system commands through the device's login username field. The device runs those commands with full root privileges — the highest level of system access possible.

Who's at risk: Any organisation running an EDS5000 device on firmware 2.1.0.0R3 or earlier. CISA has confirmed active exploitation and ordered US federal agencies to patch by 26 June 2026, per the CISA advisory.

CVSS: 9.8 — Critical. Patch today. Stop reading, go patch.

Root cause: The HTTP RPC module logs failed login attempts by building a shell command that includes the submitted username. That username is pasted directly into the command with no sanitisation (no filtering or validation of what characters are allowed). This means any input — including malicious commands — is treated as legitimate instructions by the system.

Attack vector: An attacker sends a login request to the device's HTTP interface with a username field containing injected shell commands rather than a real username. The device's logging routine picks up that input and executes it as a root-level system command. No prior authentication is needed. The attacker walks away with full control of the device — and potentially a foothold into the broader network it sits on.

Detection strategies:

1. Review HTTP authentication logs for usernames containing shell metacharacters such as semicolons, pipes, or backticks.
2. Monitor for unexpected outbound network connections from EDS5000 devices, particularly to unfamiliar external IPs.
3. Check for new or modified system files and configuration changes on the device that no administrator initiated.

Recommended actions:

1. Upgrade all EDS5000 devices to firmware version 2.2.0.0R1 immediately.
2. Place EDS5000 devices behind a firewall and restrict HTTP access to trusted management IPs only.
3. If patching is not immediately possible, isolate affected devices from the wider network until the upgrade is complete.

What Cisco Unified CM is: Cisco Unified CM is an enterprise on-premises platform that manages voice calls, video conferencing, and internal communications for large organisations — the phone system backbone for thousands of businesses.

What it is: A critical flaw in the WebDialer service component allows a remote attacker with no credentials to perform SSRF (server-side request forgery — when an attacker tricks a server into making requests on their behalf), write arbitrary files to the underlying operating system, and escalate privileges to root. The WebDialer service must be enabled for exploitation, and it is disabled by default.

Who's at risk: Any enterprise running Cisco Unified CM with the WebDialer service enabled and internet-accessible. Given Unified CM's widespread use, both financially motivated attackers and state-sponsored groups have strong incentive to exploit this.

CVSS: Not yet officially scored in public sources — treat as Critical until confirmed. CVE ID not confirmed in source as scored — check the official Cisco advisory before acting.

Root cause: The WebDialer service fails to properly validate or restrict incoming HTTP requests. It processes attacker-supplied input without checking whether the request originates from a legitimate internal source. This allows the server to be directed toward resources it should never reach.

Attack vector: An attacker sends a crafted HTTP request to the WebDialer endpoint, requiring no login. The server processes it as trusted, allowing the attacker to write a file to the OS and escalate to root. A public proof-of-concept (PoC) exploit is now available, and active exploitation has been observed from at least one source.

Detection strategies:

• Look for unexpected file creation events in OS-level logs on Unified CM nodes
• Monitor WebDialer service logs for requests containing file:// URI patterns
• Check for new or unrecognised processes running with root privileges on Unified CM hosts

Recommended actions:

1. Apply Cisco's patch, released June 3 — prioritise this immediately
2. If patching is not possible today, disable the WebDialer service until the patch is applied
3. Restrict network access to Unified CM admin interfaces to trusted IP ranges only

What FFmpeg is: FFmpeg is an open-source library used by hundreds of applications — including Kodi, OBS Studio, Jellyfin, Nextcloud, PhotoPrism, and messaging platforms like Slack and Telegram — to process, decode, and encode video files.

What it is: A heap out-of-bounds write (a memory corruption flaw where the software writes data beyond its allocated memory space, like writing past the end of a notepad and overwriting whatever is on the next page) in FFmpeg's MagicYUV video decoder. The vulnerability, nicknamed PixelSmash by researchers at JFrog, earned a CVSS score of 8.8.

Who's at risk: Anyone running software that uses FFmpeg's libavcodec library with the MagicYUV decoder enabled. This includes self-hosted media servers like Jellyfin and Nextcloud, media players like Kodi, streaming tools like OBS Studio, photo managers like PhotoPrism, and desktop thumbnail generators in GNOME, KDE, and XFCE. Plex uses a custom FFmpeg build with decoders restricted to an allowlist, which mitigates this specific risk.

CVSS: 8.8 — High. Patch this week.

Root cause: The MagicYUV decoder splits video frames into independent regions called slices, which can be decoded separately. The flaw exists because the frame allocator and the decoder calculate the height of the chroma plane (a component of colour data in video) differently. That mismatch means the decoder writes one row of pixel data beyond the end of the memory it was allocated — a one-row overflow that is small but reliably exploitable for a crash, and potentially worse under the right conditions.

Attack vector: An attacker crafts a malicious video file in AVI, MKV, or MOV format and delivers it to a target system. The flaw triggers when the file is opened directly, when a file manager generates a thumbnail preview, or when an automated media ingestion workflow — such as Jellyfin's library scan — processes the file automatically. For a denial-of-service (DoS) condition, this is reliable. For remote code execution (RCE) on Jellyfin, researchers demonstrated a full exploit, but this required ASLR (Address Space Layout Randomization — a memory protection that randomises where code is loaded to make exploitation harder) to be disabled, or chaining with a separate vulnerability to bypass it. DoS without ASLR disabled is the more realistic near-term risk for most deployments. A particularly low-friction attack scenario involves seeding a malicious video file via torrent, pointed at a Jellyfin media library — the server's own file monitor then triggers the exploit automatically, with no user action required.

Detection strategies:

1. Check application logs for FFmpeg or ffprobe crashes, segmentation faults, or unexpected process terminations — particularly during media library scans.
2. Monitor for unusual outbound network connections from your media server process, which could indicate a successful exploit on systems with ASLR disabled.
3. If running Jellyfin, review library scan logs for errors referencing MagicYUV or AVI files added around the time of any suspected incident.

Recommended actions:

1. Upgrade FFmpeg to version 8.1.2 or later. Jellyfin has already updated its bundled FFmpeg — update Jellyfin itself to get the fix.
2. If you cannot patch immediately, add AVI files containing MagicYUV-encoded video to a blocklist where your application supports it. PhotoPrism is already working on this.
3. Ensure ASLR is enabled on any server running media processing software — this significantly raises the bar for RCE exploitation.

What Squid Proxy is: Squid is a widely used open-source web proxy that organisations run to cache web traffic, reduce bandwidth, and speed up browsing for everyone sharing that network connection.

What it is: A memory leak flaw, nicknamed "Squidbleed" for its resemblance to the infamous Heartbleed bug, in Squid's FTP parser. The parser reads past the edge of its allocated memory buffer (the chunk of memory set aside to hold one piece of data) and can pull in leftover data from a previous, unrelated user's HTTP request.

Who's at risk: Organisations running an unpatched Squid instance as a shared proxy — corporate networks, schools, and public Wi-Fi hotspots are the highest-risk environments, since multiple people's traffic passes through the same Squid instance. The flaw has existed in the software since 1997.

CVSS: Not yet formally scored — treat as High given the Heartbleed-style data exposure risk it carries.

Root cause: Squid's FTP parser does not properly bound-check where it reads from in memory. When triggered, it can read beyond the data it's supposed to access and into memory still holding fragments of someone else's request — including, potentially, authentication credentials, session tokens, and API keys, if that traffic was unencrypted HTTP.

Attack vector: An attacker who controls an FTP server reachable through the proxy can trigger the bug, causing the proxy to leak fragments of another user's recent HTTP traffic. The exposure is limited to cleartext HTTP — standard HTTPS connections relayed as opaque tunnels are not affected — but cleartext HTTP credentials still travel through plenty of enterprise and legacy systems.

Detection strategies:

1. Check your Squid version against the patched releases — version 7.6 and the Squid 8 branch both include the fix.
2. Audit whether your Squid deployment has FTP support enabled at all; if it's unused, that's your simplest mitigation.
3. Review proxy logs for FTP traffic patterns from unfamiliar or unexpected upstream servers.

Recommended actions:

1. Upgrade to Squid 7.6 or the Squid 8 branch immediately.
2. If you cannot patch right away, disable FTP support in your Squid configuration as an interim mitigation.
3. If your proxy serves a shared network (office, school, public Wi-Fi), treat any cleartext HTTP credentials that passed through it during the exposure window as potentially compromised.

No notable new vulnerability disclosed in the last 24 hours.

What Gravity SMTP is: A WordPress plugin installed on roughly 100,000 websites that manages transactional email sending by connecting to third-party services like Amazon SES, Google, and Mailjet.

What it is: The plugin exposes a REST API endpoint (a URL on your website that accepts requests and returns data) that has no authentication guard. Its permission_callback (the security check that decides who can access this endpoint) unconditionally returns true, meaning anyone on the internet can query it without logging in.

Who's at risk: Any website running Gravity SMTP below version 2.1.5 with active third-party email integrations configured. No login required to exploit this.

CVSS: 5.3 (Medium — patch in your next update cycle, sooner if you have live API keys configured).

Root cause: The register_connector_data() method (the function that loads and packages the plugin's internal configuration) triggers when a specific query string is appended to the endpoint URL. Because the access check was never properly implemented, the server happily assembles and returns a detailed system report to anyone who asks. The exposed data includes API keys, OAuth tokens, your WordPress version, active plugins, database structure, and web server details — essentially a roadmap for a follow-on attack. Imagine accidentally leaving your filing cabinet open with a printed directory of every key in the building sitting on top.

Recommended actions:

1. Update Gravity SMTP to version 2.1.5 or later immediately via your WordPress dashboard.
2. If you were running a vulnerable version with email integrations configured, treat your API keys as compromised — rotate credentials for Amazon SES, Google, Mailjet, Resend, and Zoho.
3. Review your server access logs for requests to /wp-json/gravitysmtp/v1/tests/mock-data — Wordfence has blocked over 17 million exploit attempts to date, with activity spiking around June 6 and seeing peaks of over 4 million requests in a single day.

What NGINX is: NGINX is open-source web server software that sits in front of websites and applications to handle incoming traffic, widely used as a reverse proxy and load balancer across the internet.

What it is: A use-after-free flaw (a bug where software keeps using a piece of memory after telling the system it's done with it, which an attacker can exploit to corrupt that memory) in the module NGINX uses to handle HTTP/3, the newer version of the protocol that powers web traffic.

Who's at risk: Any organization running NGINX Open Source configured to use the HTTP/3 QUIC module. No login or prior access is required to attempt exploitation.

CVSS: 9.2 (Critical — patch today.)

Root cause: The HTTP/3 module mismanages memory tied to QPACK encoder streams (a compression mechanism HTTP/3 uses to shrink header data). When a connection is reopened in a specific crafted sequence, the module can end up referencing memory that has already been freed, giving an attacker a foothold to corrupt it.

Attack vector: A remote, unauthenticated attacker opens a specially crafted HTTP/3 session and reopens a QPACK encoder stream in a way that triggers the use-after-free. On systems where Address Space Layout Randomization (ASLR, a defense that randomizes where code sits in memory) is disabled, or where an attacker can bypass it, this can be escalated into full remote code execution.

Detection strategies: Watch for unusual or malformed HTTP/3 connection patterns in NGINX access logs, repeated QUIC stream resets from the same client, and unexpected NGINX worker process crashes or restarts.

Recommended actions:

1. Apply F5's patch for NGINX Open Source immediately.
2. If you cannot patch right away, disable the HTTP/3 QUIC module as an interim mitigation.
3. Confirm ASLR is enabled on affected servers as a partial defense-in-depth measure while patching is underway.

What Cisco ISE is: Identity Services Engine (ISE) is software many large organizations use to control which devices and users are allowed onto their network.

What it is: An attacker who already has valid admin login credentials can send a specially crafted request that lets them run commands directly on the server's underlying operating system, then escalate to full root access (the highest level of control on the machine).

Who's at risk: Any organization running an unpatched ISE or ISE-PIC deployment where an attacker has obtained admin credentials, through phishing, credential leaks, or reuse from breaches like FortiBleed above.

CVSS: 9.1 (Critical) — patch today.

Root cause: The software does not properly check the input it receives in certain admin requests. Because that input is not validated, the system trusts data it should be inspecting first, similar to a guard waving through anyone holding a badge without checking if the badge is real.

Attack vector: An attacker with valid admin credentials sends a crafted HTTP request to the ISE server. The server processes it without proper validation, handing the attacker user-level access to the operating system underneath. From there, they escalate their own privileges until they control the entire machine as root.

Detection strategies: Watch admin account logs for unusual command-line activity following login, check for unexpected new processes running under the ISE service account, and review for failed escalation attempts that might signal probing before a successful breach.

Recommended actions:

1. Upgrade to ISE/ISE-PIC 3.3 Patch 11, 3.4 Patch 6, or the 3.5 hotfix (3.5 Patch 4 lands in August).
2. Restrict admin portal access to trusted internal networks only.
3. Enforce MFA on all ISE admin accounts and audit recent admin logins for anomalies.

What FortiSandbox is: FortiSandbox is a cybersecurity product made by Fortinet that organisations use to detect malware and advanced threats by running suspicious files and code in an isolated environment before they reach the network.

What they are: Three critical flaws in FortiSandbox are currently being exploited in the wild, according to threat intelligence firm Defused Cyber. Two involve OS command injection (a flaw where an attacker can trick a system into running their own commands as if they were legitimate instructions from the software), and one is a path traversal vulnerability (where an attacker navigates outside the intended directory structure to access restricted files or functions). All three allow an unauthenticated attacker — meaning someone with no login credentials at all — to take unauthorised control of the affected system.

Who's at risk: Organisations running Fortinet FortiSandbox, FortiSandbox Cloud, or FortiSandbox PaaS on unpatched versions. CVE-2026-39813 and CVE-2026-39808 were patched in April 2026. CVE-2026-25089 was patched only last week and affects the web UI across all three product variants.

CVSS: 9.1 (Critical) for all three — patch today. Stop reading, go patch.

Root cause: The flaws exist because FortiSandbox failed to properly validate HTTP requests before acting on them. In the command injection cases, the software passed attacker-supplied input directly to the underlying operating system without sanitising it. In the path traversal case, the JRPC API did not restrict where in the file system an incoming request could reach — allowing authentication to be bypassed entirely.

Attack vector: An attacker with no account on the system sends a specially crafted HTTP request to an exposed FortiSandbox API endpoint or web UI. For the command injection flaws, the malformed request causes the server to execute attacker-supplied commands with the privileges of the FortiSandbox process. For the path traversal flaw, the crafted request navigates the API into an authentication bypass, granting access without credentials. No user interaction is required. Exploitation has been observed in the wild across all three CVEs within the past 24 hours.

Detection strategies: Check FortiSandbox logs for unexpected or malformed HTTP requests hitting JRPC API endpoints, particularly from external IP addresses. Look for anomalous process creation events on the FortiSandbox host — unexpected child processes spawned by the web service are a strong indicator. Monitor for any authentication events that do not correspond to known user accounts or sessions.

Recommended actions:

1. Upgrade FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS to the latest patched versions immediately — all three CVEs have fixes available.
2. Restrict access to FortiSandbox management interfaces to trusted IP ranges only, using firewall rules or network segmentation.
3. Enable logging on all API endpoints and set alerts for anomalous request patterns or unexpected process execution.

What PAN-OS is: PAN-OS is the operating system running Palo Alto Networks firewalls and network security appliances — the software layer that decides what traffic enters and leaves an organisation's network.

What it is: An authentication bypass flaw (a vulnerability that lets someone skip the identity check entirely) in PAN-OS's GlobalProtect component — the VPN gateway that allows remote workers to connect securely to corporate systems. According to Palo Alto Networks, an attacker can exploit it to establish VPN connections without valid credentials.

Who's at risk: Organisations running PAN-OS with GlobalProtect portals or gateways exposed to the internet. Active exploitation has been confirmed, with initial activity observed as far back as 17 May 2026.

CVSS: 7.8 (High — patch this week. Do not delay.)

Root cause: GlobalProtect's portal and gateway components fail to properly verify incoming connection requests. The validation step that should confirm a user is who they claim to be can be bypassed entirely, allowing an attacker to proceed as an authenticated user without ever supplying legitimate credentials.

Attack vector: An attacker sends a crafted request to the GlobalProtect portal or gateway. The system accepts it without completing proper authentication and establishes a VPN session. Palo Alto confirmed that only a fraction of probed devices completed full sessions, but those that did registered as gateway-connected events, placing the attacker inside the network perimeter. No post-access lateral movement (the act of moving from one internal system to another after gaining initial entry) has been identified yet, but the window for it remains open on unpatched devices.

Detection strategies:

1. Audit GlobalProtect gateway logs for VPN sessions from unrecognised source IP addresses, particularly from mid-May 2026 onwards.
2. Look for gateway-connected events with no corresponding legitimate user login record.
3. Flag any unusual admin activity or new account creation following suspicious VPN sessions.

Recommended actions:

1. Apply Palo Alto's current PAN-OS patch immediately. This is actively exploited.
2. Where operationally possible, restrict GlobalProtect portal access to known, approved IP ranges.
3. Review all VPN session logs from mid-May onwards and investigate anything anomalous before clearing it.