Author Archives: CERT

Overview

Retell AI’s API creates AI voice agents that have excessive permissions and functionality, as a result of insufficient amounts of guardrails. As a result, attackers can exploit this and conduct large scale social engineering, phishing, and misinformation campaigns.

Description

Retell AI offers an API that can create human sounding voice agents that can then be tasked to perform various business operations, respond to questions, and be automated to complete various other voice related tasks. Retell AI uses OpenAI’s GPT 4o and 5 models for these conversations, and users can configure agents with minimal prompt engineering.

However, Retell AI’s lack of sufficient guardrails causes the LLM to respond in unexpected ways and deliver malicious outputs. Guardrails are an important mechanism in LLMs that filter inputs and outputs to ensure models are behaving in intended ethical ways. Retell AI permits voice AI agents to have over-permissive autonomy with the lack of guardrails. This is known as Excessive Agency. Malicious actors need minimal resources and technical knowledge to induce trust, extract data, and conduct large scale phishing operations using Retell AI products.

Impact

The vulnerability targets Retell AI’s ease of deployment and customizability to perform scalable phishing/social engineering attacks. Attackers can feed publicly available resources as well as some instructions to Retell AI’s API to generate high-volume and automated fake calls. These fake calls could lead to unauthorized actions, security breaches, data leaks, and other forms of manipulation.

Solution

Retell AI has not released a statement, and coordinated disclosure was attempted. Users should be aware and follow security best practices when speaking to an AI voice agent and avoid sensitive data input. Developers should limit functionality and permissions through instating sufficient guardrails and implement manual human approval for high-risk or high volume tasks.

Acknowledgements

Thanks to the reporter, Keegan Parr, for the report. The reporters disclosure is available here: https://haxor.zip/ This document was written by Ayushi Kriplani.

Continue reading VU#649739: Lack of Sufficient Guardrails Lead to Excessive Agency (LLM08) in Some LLM Applications→

Overview

A command injection vulnerability exists across multiple firmware versions that allows an attacker to execute arbitrary commands as root on the affected device. Currently, no solution exists to resolve these vulnerabilities in the Tenda N300 series and Tenda 4G03 Pro devices.

Description

Tenda 4G03 Pro is a portable 4G LTE router that is designed to provide for flexible internet access. It is a plug-and-play device compatible with mobile operators globally, allowing you to insert a SIM card for ad-hoc internet access. Multiple components within this model of Tenda 4G LTE router is impacted by command injection flaws that stem from improper handling of attacker-controlled input passed to internal service functions.

CVE-2025-13207
In Firmware up to and including v04.03.01.44, manipulation of arguments passed to a function within the service /usr/sbin/httpd can be exploited. A crafted, authenticated HTTP request to TCP port 80 can trigger arbitrary command execution.

CVE-2024-24481
In Firmware up to and including v04.03.01.14, improper input handling within an accessible function leads to a similar command injection condition. An authenticated attacker can invoke the function through the web interface, after which a crafted network request to TCP port 7329 can result in command execution. This issue is distinct from CVE-2023-2649.

These vulnerabilities were identified through reverse engineering of the firmware. At this time, no fixed firmware is available to address these vulnerabilities.

Impact

Successful exploitation allows an attacker to execute arbitrary commands as root on the underlying operating system, allowing attacker to take Total control of the device.

Solution

The CERT/CC is currently unaware of a vendor-supplied patch or mitigation for these vulnerabilities.

• Use an alternative device: Because no remediation is currently available, users who rely on this device in security-sensitive may consider other devices for such access.
• Reduce exposure where possible: If replacement is not immediately feasible, limit usage to reduce risk of abuse.
• Monitor for vendor updates: Users should periodically check for firmware updates or advisories from Tenda in case a patch becomes available in the future.

Acknowledgements

Thanks to the reporter Ax for reporting this issue. This document was written by Marisa Middler and Timur Snoke.

Continue reading VU#268029: Tenda N300 Wi-Fi 4G LTE Router 4G03 Pro impacted by vulnerabilities→

Overview

Wolfram Cloud version 14.2 allows Java Virtual Machine (JVM) unrestricted access to temporary resources in the /tmp/ directory of the cloud environment which may result in privilege escalation, information exfiltration, and remote code execution. In the same cloud instance, temporary directories of other users may be accessible.

Description

Wolfram Cloud is a multi-tenant cloud platform that supports a virtual “notebook” interface for easier programming and accessibility to tools for quickly building and publishing integrated applications. In this architecture, the instance kernel /tmp/ directory is shared, but with access permissions. Excepting the JVM initialization file, these temporary directories usually do not contain sensitive information. A newly discovered race condition allows attackers to poison the classpath via the shared /tmp/ directory during JVM initializaiton. If an attacker can approximate when users would be launching the JVM, access to an unprotected temporary directory may be successful.
The cause is the implementation of the virtual environment by the hosting platform which manages access to temporary files in a multi-tenant cloud environment. A successful attack will give the attacker access to the temporary directories of other users.

Impact

An attacker that accesses the shared /tmp/ directory of the instance can potentially achieve privilege escalation, information exfiltration, and remote code execution.
This constitutes a Technical Impact = Total under the SSVC framework, meaning:

The vulnerability gives the adversary total control over the behavior of the software or total disclosure of all information on the affected system.

Solution

The CERT/CC recommends updating Wolfram Cloud to version 14.2.1.

Acknowledgements

Thanks to the reporter Peter Roberge from Pointer Cybersecurity. This document was written by Laurie Tyzenhaus and Renae Metcalf.

Continue reading VU#553375: Unprotected temporary directories in Wolfram Cloud version 14.2 may result in privilege escalation→

Overview

Lite XL is a lightweight text editor derived from the lite project, written primarily in Lua and C. It supports Windows, Linux, and macOS, and is designed for extensibility through plugins and project‑specific modules.

Description

Two vulnerabilities were identified Lite XL:

CVE-2025-12120
Lite XL versions 2.1.8 and prior automatically execute the .lite_project.lua file when opening a project directory, without prompting the user for confirmation. The .lite_project.lua file is intended for project-specific configuration but can contain executable Lua logic. This behavior could allow execution of untrusted Lua code if a user opens a malicious project, potentially leading to arbitrary code execution with the privileges of the Lite XL process.

CVE-2025-12121
Lite XL versions 2.1.8 and prior contain a vulnerability in the system.exec function, which allowed arbitrary command execution through unsanitized shell command construction. This function was used in project directory launching (core.lua), drag-and-drop file handling (rootview.lua), and the “open in system” command in the treeview plugin (treeview.lua). If an attacker could influence input to system.exec, they might execute arbitrary commands with the privileges of the Lite XL process.

Impact

CVE-2025-12120
When opening a project in Lite XL, the project’s Lua module was executed automatically, potentially allowing malicious code in a repository to run without user consent.

CVE-2025-12121
The legacy system.exec function allowed arbitrary shell command execution, which could be abused to compromise the host system.

Affected versions

Lite XL versions 2.1.8 and prior

Solution

Users should update to the latest version of Lite XL that includes these pull requests:

PR #1472 – Adds in a trust guard for project modules.
PR #1473 – Removed legacy exec function.

These updates ensure that untrusted projects cannot automatically execute Lua code and that unsafe system calls are no longer available.

Acknowledgements

Thanks to the reporter Dogus Demirkiran for reporting these vulnerabilities. Additional thanks to GitHub user Summertime for also identifying CVE-2025-12120 and opening Issue #1892 on GitHub. This document was written by Marisa Midler.

Continue reading VU#579478: Lite XL Arbitrary Code Execution via Project Module and Legacy system.exec Function→

Overview

The npm package expr-eval is a JavaScript library that evaluates mathematical expressions and is used in various applications, including NLP and AI. A vulnerability in this library has been disclosed that could allow arbitrary code execution by an attacker using maliciously crafted input.

Description

The npm projects expr-eval and expr-eval-fork are JavaScript libraries used to parse and evaluate mathematical expressions, extending NLP applications that process mathematical expressions and their numerical data. This capability is particularly useful in generative AI systems that need to interpret mathematical expressions within user prompts. The Parser class and its evaluate() method is designed to provide user-defined expressions in a safer way than JavaScript’s native eval() function. This design choice is critical for npm-based projects, especially those running in server environments where access to a system’s local resources could pose security risks. According to npmjs.com, expr-eval has over 250 dependent packages, including integrations such as oplangchain, a JavaScript implementation of the popular LangChain framework. The related project expr-eval-fork was created to address a prior Prototype Pollution vulnerability (Issue #266) that remained unresolved in the original expr-eval repository, which appears to be unmaintained by the original author, with last release date of 2019-09-28.

A newly discovered vulnerability allows an attacker to define arbitrary functions within the context object used by the parser. This capability can be exploited to inject malicious code that executes system-level commands, potentially accessing sensitive local resources or exfiltrating data. This issue has been patched via Pull Request #288. The vulnerability is tracked with CVE-2025-12735, as well as the GitHub Advisory GHSA-jc85-fpwf-qm7x. These identifiers enable automated tools such as npm audit to detect the vulnerability in affected projects. The CVE-2025-13204 has also been published for the earlier Prototype Pollution vulnerability identified in 2021 that is not fixed in expr-eval, however the expr-eval-fork released in 2024-01-10.

Impact

An attacker with the ability to influence input fields processed by expr-eval can craft malicious payloads that trigger arbitrary command execution on the host system.
This constitutes a Technical Impact = Total under the SSVC framework, meaning:

The vulnerability gives the adversary total control over the behavior of the software or total disclosure of all information on the affected system.

Solution

Developers and Users are advised either to:

1. Apply the security patch from Pull Request #288, or
2. Upgrade to the latest patched version of the expr-eval or expr-eval-fork package as they become available. The newly released expr-eval-fork 3.0.1 has been tested to resolve this issue.

Note: The patch introduces:

• A defined AllowList of safe functions accessible via evaluate()
• A mandatory registration mechanism for custom functions.
• Updated test cases ensuring enforcement of these constraints can be understood and applied

Acknowledgements

Thanks to the reporter Jangwoo Choe (UKO) for responsibly disclosing this issue. Thanks to huydoppaze for improving the suggested patch. We also acknowledge GitHub Security and npm for their proactive security advisories and automated vulnerability audits. This document was written by Vijay Sarvepalli and Renae Metcalf.

Continue reading VU#263614: Vulnerability in expr-eval JavaScript library can lead to arbitrary code execution→

Overview

Email message header syntax can be exploited to bypass authentication protocols such as SPF, DKIM, and DMARC. These exploits enable attackers to deliver spoofed emails that appear to originate from trusted sources. Recent research has explored using the originator fields, such as From: and Sender:, to deliver spoofed emails that appear to come from trusted sources. Attackers can abuse these fields to impersonate an originator email address for nefarious purposes.

Description

Email is a primary medium for both personal and business communication. In recent years, mechanisms such as DKIM, SPF, and DMARC have been developed to verify the identity of email senders; however, end-to-end secure email remains an unsolved challenge.

A previous disclosure, dubbed SMTP Smuggling, highlighted ways in which a sender’s identity could be spoofed while abusing the SMTP protocol as defined in RFC 5321. Further research shows that email message headers, as defined in the Internet Message Format (RFC 5322, updated by RFC 6854), can also be used to spoof the identity of an email sender.

In a typical scenario, an email passes SPF, DKIM, and DMARC checks, and there is one sender with an envelope header MAIL FROM field that matches the mail header From: and optional Sender: fields. RFC 6854 defines how an email may be sent on behalf of a group, putting multiple email addresses in the mail header From: field.

Using specialized syntax, an attacker can insert multiple addresses in the mail header From: field. Many email clients will parse the From: field to only display the last email address, so a recipient will not know that the email is supposedly from multiple addresses. In this way, an attacker can pretend to be someone familiar to the user.

More specifically, user attacker@example.com could send an email with the From: field formatted as <attacker@example.com>:<spoofed@example.com>. The receiving server may display spoofed@example.com as the sender. Additionally, the sending server may add DKIM signatures and forward the email in a way that aligns with SPF policies, causing the receiving system to treat the message as trusted.

These crafted email headers can take several forms, using combinations of quotation marks and angle-address notation (e.g., <attacker@example.com>), as discussed in Solnser’s 2024 blog post: https://blog.slonser.info/posts/email-attacks/. Attackers can also use the null sender <>, or “null reverse path,” as specified in RFC 5321 Section 4.5, further complicating genuine sender authentication.

Impact

An attacker can craft email headers to impersonate other users, bypassing DMARC policies and sender verification enforced by a domain owner. Research has demonstrated that multiple email service providers are susceptible to this type of attack.

Solution

Email Service Providers and Administrators

Email service providers should implement measures to ensure that authenticated outgoing email headers are properly verified before signing or relaying messages. Additionally, software built using the Mail Filter (milter) protocol, such as Milterfrom version 1.0.4, has recent updates to better verify authenticated senders for milter-compliant email servers.

Email End Users

Because email sender verification remains challenging, users should exercise caution when responding to emails requesting sensitive information or clicking links that may download or install malicious software. Users that want to verify the originator of an email before clicking links or sharing sensitive information can check the original headers for the From: and Sender: fields by viewing the “Original Message” or “Message Source,” depending on the email client.

Acknowledgements

Thanks to Hao Wang and Caleb Sargent from PayPal for reporting these issues. This document was written by Vijay Sarvepalli and Renae Metcalf.

Continue reading VU#517845: Authenticated SMTP users may spoof other identities due to ambiguous “From” header interpretation→

Overview

Browser-extension password managers, which autofill sensitive information on websites, can be exposed to various clickjacking attacks. These attacks exploit the trust relationship between a web page and the user-interface elements injected by the extension. Recent studies show that Document Object Model (DOM-level) manipulation can bypass many standard clickjacking defenses, leaving several password managers at risk when users navigate to a malicious or compromised website. Users should promptly install vendor updates and carefully weigh the security risks of using password-manager features such as autofill of sensitive information that trade convenience for potential exposure

Description

Clickjacking is a malicious technique that usually involves tricking a user into clicking something that looks safe or normal to interact with so that an attacker can gain some kind of sensitive information or perform an action that they otherwise would not be able to do.

Though clickjacking is a well known attack that has many mitigations across many product areas, novel methods of execution still appear. Unlike traditional iframe-based clickjacking attacks, DOM-based clickjacking exploits the fact that browser extensions can sometimes allow interactive elements to be injected directly into a website’s DOM. DOM is desribed in stands MDN Web Docs as

the data representation of the objects that comprise the structure and content of a document on the web. It represents the page so that programs can change the document structure, style, and content. The DOM represents the document as nodes and objects; that way, programming languages can interact with the page (MDN Web Docs).

Since JavaScript has the ability to manipulate the visual elements injected by a browser extension, these elements can be made invisible to the user while preserving click handlers so that attackers can trick users to interact with password manager extension functions. This behavior can be guided by website elements that users are already feel safe and familiar with such as cookie consent banners, pop-up ads, or CAPTCHA prompts.

Password managers inject user-interface elements into web pages to enable autofill functionality, creating an inherent tension between usability and security. Clickjacking exploits rely on user interaction with maliciously crafted content, making responsibility for mitigation a shared concern. Effective defenses require coordinated effort: web developers must implement clickjacking protections, password-manager vendors must harden extension behavior, and users must understand and manage residual risk. No single party can eliminate the vulnerability on its own.

Impact

Successful clickjacking of a browser-extension password manager could allow an attacker to trick users into unintentionally revealing or auto-filling credentials, leading to unauthorized access to sensitive accounts and stored passwords. Because DOM-based techniques can bypass common defenses, multiple browsers and password-manager vendors remain variably exposed while mitigations continue to evolve.

Solution

Review the Vendor Information section for any browser or password manager extension specific updates and mitigation steps. Apply the latest updates from both the browser and the password-manager extension vendors. Where applicable, users should consider disabling or limiting autofill functionality or adjusting related settings to reduce exposure when concerned about clickjacking exposure. Users must also recognize that the level of control may vary from product-to-product, and that clickjacking attempts may occur on trusted websites if they have been compromised.

Acknowledgements

Thanks to Marek Tóth in presenting the research and Jonathan Leitschuh for reporting this research to us. This document was written by Ben Koo.

Continue reading VU#516608: Multiple Password Managers Vulnerable to Clickjacking Attacks→

Overview

A vulnerability in cross-origin resource sharing (CORS) headers in Chromium, Google Chrome, Microsoft Edge, Safari, and Firefox enables the CORS policy to be manipulated. Combined with a DNS rebind, an attacker can send arbitrary requests to services listening on arbitrary ports regardless of CORS policy in place by the target. Users should apply the mitigations provided by the browser suppliers by applying the updates accordingly.

Description

Cross-origin resource sharing is a mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own that are permitted to load resources in the browser. For example, when a website needs to access your account data from a different website, a CORS policy is usually one of the best ways to set up that communication. However, CORS can be incorrectly implemented depending on the use case. As a result, attackers can exploit CORS misconfigurations or even chain them with other vulnerabilities to affect a system.

A DNS rebinding attack abuses the way browsers rely on hostnames to recognize different servers across a network. Hostnames are not directly bound to network devices and can be resolved to an arbitrary IP address dictated by a domain owner’s DNS record. Attackers can abuse a victim’s browser as a proxy to extend the attack surface to private networks. For example, an attacker tricks a victim into opening a malicious website where it scans for open web services in local networks. After locating target services, the attacker can then make an educated guess as to which of those services’s IP address to rebind to the malicious website in order to access its resources without violating the same-origin policy.

The ability to conduct a DNS rebinding attack and manipulating CORS headers in order to enable malicious exfiltration of data has been observed to be successful on Chromium, Google Chrome, Microsoft Edge, Safari, and Firefox. An attacker can use a malicious site to execute a JavaScript payload that periodically sends CORS headers in order to ask the server if the cross-origin request is safe and allowed. Naturally, the attacker-controlled hostname will respond with permissive CORS headers that will circumvent the CORS policy. The attacker then performs a DNS rebind attack so that the hostname is assigned the IP address of the target service. After the DNS responds with the changed IP address, the new target inherits the relaxed CORS policy, allowing an attacker to potential exfiltrate data from the target.

Mozilla has assigned CVE-2025-8036 for this vulnerability.

Impact

The impact depends on the target. Exposure of private networks and unauthorized access to sensitive data are all within the realm of possibility.

Solution

DNS rebind attacks can have serious consequences when exploited, so we recommend keeping your browser up to date for the latest vulnerability patches.

Acknowledgements

Thanks to the reporter who wishes to remain anonymous. This document was written by Ben Koo.

Continue reading VU#652514: DNS Rebinding and Manipulating CORS Headers Enables Exfiltration of Information→

Overview

Clevo’s UEFI firmware update packages included sensitive private keys used in their Intel Boot Guard implementation. This accidental exposure of the keys could be abused by an attacker to sign malicious firmware using Clevo’s Boot Guard trust chain, potentially compromising the pre-boot UEFI environment on systems where Clevo’s implementation has been adopted.

Description

Intel Boot Guard is a platform integrity technology, providing a root of trust that protects the earliest stages of the boot process. It cryptographically verifies the Initial Boot Block (IBB) and prevents the execution of untrusted firmware. Operating before UEFI is initialized, Boot Guard ensures that only authenticated firmware is executed during the earliest pre-boot stage. Boot Guard is often confused with UEFI Secure Boot, but Secure Boot operates later in the process, enforcing trust within the UEFI firmware execution phase and during the transition from UEFI to the operating system.

Clevo Co. is a computer hardware and firmware manufacturer that operates as both an Original Design Manufacturer (ODM) and an Original Equipment Manufacturer (OEM), producing laptops and UEFI firmware used by various personal computer brands. One of Clevo’s publicly released UEFI software executables included private keys integral to its Boot Guard trust chain. Because Clevo’s firmware is integrated into products from other manufacturers, the exposure may have supply chain implications extending beyond Clevo-branded systems.

Impact

An attacker with write access to flash storage for a system, whether through physical access or a privileged software update mechanism, could abuse the leaked keys to sign and install malicious firmware. Such firmware would be trusted at the early stages that will be protected by Boot Guard, allowing compromise of the affected UEFI systems and thus enabling persistent and stealthy control over the device.

Solution

While Clevo has reportedly removed the affected software containing the leaked keys, no public remediation steps have been announced by Clevo at this time.
Users of Clevo-based devices, including those from other OEMs that integrate Clevo firmware, should:
* Assess their exposure to affected firmware versions.
* Monitor systems for unauthorized firmware modifications.
* Apply firmware updates only from verified and trusted sources.

Acknowledgements

This issue was responsibly disclosed by the Binarly Research Team, with initial reporting by Thierry Laurion. This document was written by Vijay Sarvepalli.

Continue reading VU#538470: Clevo UEFI firmware embedded BootGuard keys compromising Clevo’s implementation of BootGuard→

Overview

The Kiwire Captive Portal, provided by SynchroWeb, is an internet access gateway intended for providing guests internet access where many users will want to connect. Three vulnerabilities were discovered within the product, including SQL injection, open redirection, and cross site scripting (XSS), allowing an attacker multiple vectors to compromise the device. All three of the vulnerabilities have been addressed by the vendor. Customers using the Kiwire Captive Portal are recommended to update to the latest version of the product to remediate the vulnerabilities.

Description

The Kiwire Captive Portal is a guest wifi solution that provides users with internet access through a login system. The product is used in various different capacities across different enterprises, including hotels, office systems, and other companies. Three vulnerabilities have been discovered within the product that allow an attacker to compromise the Kiwire Captive Portal database, redirect users to a malicious website, and trigger JavaScript upon visiting the captive portal with the malicious payload appended in the URL.

The following is a list of the CVE assignments and their respective vulnerability details:

CVE-2025-11188
The Kiwire Captive Portal contains a blind SQL injection in the nas-id parameter, allowing for SQL commands to be issued and to compromise the corresponding database.
CVE-2025-11190
The Kiwire Captive Portal contains an open redirection issue via the login-url parameter, allowing an attacker to redirect users to an attacker-controlled website.
CVE-2025-11189
The Kiwire Captive Portal contains a reflected cross-site scripting (XSS) vulnerability within the login-url parameter, allowing for JavaScript execution.

Impact

The vulnerabilities allow an attacker to exfiltrate sensitive data from the Kiwire Captive Portal database (CVE-2025-11188), redirect a user attempting to login to the captive portal to a malicious website (CVE-2025-11190), and execute JavaScript on the device that is attempting to login to the captive portal (CVE-2025-11189). It should be noted that in regards to CVE-2025-11189 and CVE-2025-11190, the domain is automatically trusted on most devices, due to it being a local address that users must access prior to being granted internet access.

Solution

A security advisory is available on the Kiwire website: https://www.synchroweb.com/release-notes/kiwire/security
SynchroWeb will be contacting individuals who use affected version to assist in their patching process.

Acknowledgements

Thanks to the reporters, Joshua Chan (josh.chan@lrqa.com) and Ari Apridana (ari.apridana@lrqa.com) of LRQA. This document was written by Christopher Cullen.

Continue reading VU#887923: Kiwire Captive Portal contains 3 web vulnerabilities→