CVE-2026-54213: Restart? No, Denial of Service#

To map the application’s attack surface, we extracted the embedded strings from the TeamDavid® binary and enumerated the endpoints they referenced. One path stood out: /internalRestart.

Despite its name, the endpoint does not restart anything. A single request to it shuts the web server service down entirely, and the application stays offline until an administrator brings it back by hand. Because the endpoint is reachable without authentication, one unauthenticated request is enough to take the service offline: an unauthenticated, single-request Denial of Service (DoS).

CVE-2026-54218 and CVE-2026-54203: Insecure Password Storage & Memory Leak#

We installed TeamDavid® locally and started digging properly. The architecture is almost entirely file-based, and, as we will see, the server is careless with the memory it reuses between requests. That becomes relevant for a vulnerability that follows this one.

Access control for user data such as personal mailboxes is handled by an access.ini file in each user’s directory, containing the username and an “encrypted” password:

[DvISE Archive Access Form]
UserName=test
Password=43 72 59 70 54 3A 20 C3 EE EC E4 F6 E4 F2 F2 E4 E8 FE E2 E3 E3 A2 AF E9 FE E7 E1 B4 C5 F9 D4 B8 EE F5 E9 F7 EE BF

Except it isn’t encrypted, just obfuscated. The scheme XORs each character against a derived key of 128 plus the character’s index position. Anyone who can read the file can recover the plaintext:

encoded = "43 72 59 70 54 3A 20 C1 C3 C1 C7 C1 C3 C1 CF C1 C3 C1 C7 C1 C3 C1 DF C1 C3 C1 C7 C1 C3 C1 CF C1 C3"
original = ''.join([chr(int(curchar,16) ^ index + 128) for index, curchar in enumerate(encoded[21:].split())])
print(original)

# The script returns "ABCDEFGHIJKLMNOPQRSTUVWXYZ".

(In some instances the password is stored in plaintext outright. We couldn’t pin down exactly what triggers that.)

Reversible storage only matters if you can reach the file, so the next question was whether we could pull sensitive data remotely. We could, though not the way we first assumed. The part of the URL after mta-sts. is used as a file extension: the unauthenticated /.well-known/mta-sts. endpoint reads mta-sts.<ext> from a fixed directory and returns it. The mta-sts stem and the directory are fixed, so this is not arbitrary file read. A request for mta-sts.test returns that file if it exists, but files with any other name in the same directory stay out of reach.

The vulnerability is triggered when the requested file is missing. The handler allocates its response buffer with malloc(), and if the file cannot be opened it skips the ReadFile() call but continues processing the uninitialized buffer. Instead of returning an error, it treats the leftover heap contents as a C string and sends them back in an HTTP 200 response. As a result, an attacker can retrieve up to 4 kilobytes of residual heap memory from previous requests simply by requesting an extension for which no corresponding file exists.

Here’s some abstracted code to understand what’s actually happening:

// path = <install>\...\mta-sts.<ext>   (<ext> is copied from the request URL)

if (stat(path, &st) == 0)          // does the file exist
    size = st.size + 200;
else
    size = 0x1000;                 // defaults to 4096 bytes

buf = malloc(size);                // buffer allocated but not zeroed
fh  = open(path);                  // open file

if (fh != INVALID_HANDLE) {        // only entered when the file actually opened
    n = ReadFile(fh, buf, size);   
    buf[n] = '\0';                 
    close(fh);
}

if (buf != NULL && buf[0] != '\0') // checks if the memory allocation succeeded and the first byte isn't the null-terminator 
    send(buf, strlen(buf));        // uninitialized heap is sent to the client

Poll the endpoint for a while and sensitive residue spills out, including the access.ini contents above and an email. Other data recovered from the leaked memory included email attachments, configuration files, and SQL queries: Put the two together and the chain is complete: recover an access.ini from the leaked memory, decode the password, and log in: unauthenticated access to any user’s mailbox:

CVE-2026-54209, CVE-2026-54210, CVE-2026-54211, CVE-2026-54212: Buffer Overflows Everywhere#

The application has several file upload features that are vulnerable to buffer overflows. If an attacker uploads a file with an excessively long filename, they can crash the server and cause an immediate DoS:

Another buffer overflow exists within the application’s API endpoint. If an unauthenticated attacker sends a HTTP request body containing a number followed by at least seven random characters, the server will crash, resulting in another DoS.

The application’s /<user>/serverClient_close.html endpoint contains a buffer overflow vulnerability affecting multiple form data parameters (ATCTOLINE, ATCCCLINE, and numberCount). By submitting excessively long values to any of these parameters, an authenticated attacker can crash the server.

The application’s password-change feature edits a user’s Archive.ini through an (editini) directive appended to the URL, of the form .../(editini)<path-to-ini-file>. The handler loads the file at that path into a fixed-size stack buffer but never verifies that the path actually points to an Archive.ini file. An unauthenticated attacker can therefore point (editini) at an arbitrary, oversized file; when the handler reads it into the undersized buffer, the buffer overflows and the server crashes.

In our testing, triggering these overflows consistently terminated the process with STATUS_STACK_BUFFER_OVERRUN. Because the cookie check intercepts the smashed stack before the vulnerable function returns, a straightforward return-address overwrite is blocked. Depending on the state of the stack, or if an attacker can defeat this protection by leaking a stack canary through another vulnerability, these flaws could still potentially be escalated to Remote Code Execution (RCE), leading to a full compromise of the underlying server:

CVE-2026-54216, CVE-2026-54217: Reflected and Stored Cross Site Scripting (XSS)#

The web application contains a reflected cross-site scripting (XSS) vulnerability. By sending a link including the parameter !templateName=entryMail and an arbitrary path as the payload (or the additional parameter EntryInfo carrying a payload), the XSS vulnerability is triggered:

Additionally, a Stored XSS vulnerability exists within the application’s email functionality. An attacker can send an email containing malicious JavaScript. When the receiving user opens this email, the script automatically executes.

CVE-2026-12071, CVE-2026-54199, CVE-2026-54214, CVE-2026-54215: Open Redirects and Header Injections#

The application contains multiple open redirect vulnerabilities. The first is a classic open redirect via the replyUrl parameter:

The second instance allows a user to control the HTTP Content-Type via the ctype parameter. Because the application improperly sanitizes URL-encoded newline characters (CRLF) before reflecting them in the HTTP response, it is vulnerable to HTTP Header Injection. An attacker can leverage this to append arbitrary headers, such as a malicious Location header, to force an open redirect: The length of the input parameter is limited, which is why only short payload URLs are possible. Theoretically, this could also be abused for a reflected XSS attack, but the allowed number of characters is too low.

Another header injection issue causes a second Open Redirect. When the server sends a 302 redirect, it builds the new URL by simply adding the requested path to the base domain. An attacker can use URL-encoded characters, like %2e (which stands for a dot), to change the end of the domain name (the TLD). For example, if the app is hosted on a .com domain, an attacker could inject %2epany to trick the server into redirecting users to a malicious .company domain that the attacker controls.

Attackers can also use URL-encoded line feeds to inject arbitrary HTTP response headers or body content. However, browsers typically ignore the injected content because of the 302 redirect status.

An attacker can exploit these vulnerabilities to craft a link on the trusted domain that redirects users to an external site. This is a classic vector for phishing attacks, tricking users who trust the initial domain name.

A separate header injection vulnerability exists in the application’s link storing feature (/<User>/ServerClient_celink.htm). The application takes input from the request body and appends it to the 302 redirect target. By including a line feed in this input, an attacker can once again control the HTTP response headers. As the Location link is already present, this doesn’t result in an open redirect vulnerability.

CVE-2026-54204, CVE-2026-54205, CVE-2026-54206, CVE-2026-54207: Server-Side Request Forgery (SSRF) via UNC Paths#

The application improperly trusts user input when constructing file paths on the server. Because it resolves Universal Naming Convention (UNC) paths (e.g., \\Attacker-IP\Share), this flaw leads to Server-Side Request Forgery (SSRF). As long as outbound traffic on port 445 (SMB) is permitted, an attacker can force the server to authenticate to a malicious machine, enabling NetNTLM hash capture or SMB relay attacks. The search functionality can be used without authentication and accepts a pathnameroot parameter, which can be pointed to external network locations using these UNC paths. Including ../ in the URL is required to bypass the application’s authorization checks:

This same vulnerability exists within the application’s link storing functionality (/<User>/ServerClient_celink.htm). The endpoint accepts a pathname parameter that can also be directed to external UNC network locations. However, unlike the search feature, exploiting this specific endpoint requires the attacker to be authenticated: Similarly, the application’s move archive functionality (!ArcEntryMove) accepts an arbitrary path that can be directed to external network locations. As with the previous endpoint, this exploit requires the attacker to be authenticated:

The path can also be directed to other users’ folders, causing the moved archives and emails to appear in their inboxes.

Additionally, the application’s message sending features (email, fax, SMS) support an @@INCLUDE command. This command also accepts UNC paths pointing to external network locations. As with the previous examples, exploiting this requires the attacker to be authenticated:

CVE-2026-12070, CVE-2026-54200, CVE-2026-54202: How not to handle files: Path Traversal, LFI, Arbitrary File Deletion#

The application’s messaging features (email, fax, SMS) are vulnerable to Local File Inclusion (LFI). An authenticated attacker can use the @@attach command within the scjob form field to attach local server files to a message, which they can then download. While a filter is in place to block access to the main configuration and user directories, this protection can be bypassed using NTFS Alternate Data Streams (by appending ::$data or ::$INDEX_ALLOCATION to the file path). This bypass allows an attacker to exfiltrate sensitive files, such as the server’s private key or access.ini files containing other users’ passwords. This messaging functionality is also vulnerable to Arbitrary File Deletion. By specifying the @@COMMENTFILE command in the scjob form field, an authenticated attacker can delete any file on the underlying server. The archive creation feature is vulnerable to Path Traversal. Because the application does not validate the user-supplied archive path, an attacker can manipulate the input to escape the intended directory structure. This flaw allows an authenticated attacker to create new folders in arbitrary locations across the server. This includes writing to sensitive system directories (such as C:\Windows) or creating folders within the private directories of other users. The folder 0 is created (this is incremental):

CVE-2026-54208: Arbitrary File Write to Stored XSS#

The password change functionality contains an arbitrary file write vulnerability. Because user input is saved without file type validation, an unauthenticated attacker can create or modify files using attacker-controlled content. However, this write access is restricted by the application’s directory permissions. The server checks the access.ini file in the target directory before allowing a write operation. An attacker cannot write to a directory if it lacks an access.ini file or if that file contains another user’s credentials. Despite these restrictions, an attacker can still write to permitted directories. By creating malicious files (such as .htm documents containing JavaScript), they can turn this file write flaw into a Stored Cross-Site Scripting (XSS) vulnerability. When a user accesses a file created in this way, the JavaScript payload is triggered.

CVE-2026-54201: Missing Authorization#

Error log files can be accessed simply by browsing to a predictable URL. The application does not enforce authentication or authorization checks when serving these log files. As a result, attackers can obtain sensitive error information or internal application details, potentially aiding in further attacks.