Vulnerabilities

Observability endpoints in the djust pip package (a Django live-view framework) expose live view/session state and a remote method-invocation surface (`eval_handler`) over the network. The localhost-only restriction was implemented as an opt-in middleware that the documented setup omits, while the endpoint views themselves enforced only the DEBUG flag, so in the documented configuration with DEBUG=True a non-localhost client could reach these endpoints without authentication. An attacker gains disclosure of live application and session state (CWE-668) plus the ability to remotely invoke handlers (CWE-306), yielding both confidentiality and integrity impact. Anyone running djust versions prior to 1.0.7 without the optional middleware and with the observability endpoints reachable from an untrusted network is affected. No public proof-of-concept is known and the flaw is not listed in CISA KEV.

Do: Upgrade to djust 1.0.7 or later, which enforces the localhost restriction in-view on every observability endpoint and restricts `eval_handler`. Ensure DEBUG=False in production and do not expose the observability endpoints to untrusted networks; check access logs for external requests to these endpoints on pre-1.0.7 deployments.

A security vulnerability has been detected in ag-ui-protocol ag-ui 1.0. This affects an unknown function of the file sdks/community/go/pkg/client/sse/client.go of the component SSE Client. Such manipulation leads to resource consumption. The attack can be executed remotely. The pull request to fix this issue awaits acceptance.

A weakness has been identified in ag-ui-protocol ag-ui 1.0. The impacted element is the function prepareRunAgentInput of the file agent/agent.ts of the component Event Application Layer. This manipulation of the argument TEXT_MESSAGE_START causes origin validation error. Remote exploitation of the attack is possible. The pull request to fix this issue awaits acceptance.

A security flaw has been discovered in ag-ui-protocol ag-ui 0.3.0. The affected element is the function create_strands_app of the file integrations/aws-strands/python/src/ag_ui_strands/utils.py of the component CORSMiddleware. The manipulation results in permissive cross-domain policy with untrusted domains. The attack may be launched remotely. The attack requires a high level of complexity. The exploitability is described as difficult. Upgrading to version [email protected] is sufficient to fix this issue. The patch is identified as 9b143b9668fa52c2054ede9d34a45ac4b4401089. It is suggested to upgrade the affected component.

CVE-2026-88817 is an improper access-control flaw in Curiosity Workspace in which any authenticated, non-guest user can enroll themselves as an administrator and member of an existing access group without receiving an invitation or approval, indicating a missing authorization check on the group-enrollment function. An attacker triggers it simply by authenticating with a valid standard (non-guest) account and issuing a self-enrollment request to join a targeted group. The attacker gains administrative/member privileges within that access group, potentially exposing or allowing modification of the content and resources shared with that group, though the flaw does not confer application-wide administrator rights or root access to the application or its host. Any organization running Curiosity Workspace with non-guest user accounts is affected. There is no known exploitation, no public proof of concept, and the issue is not listed in CISA's KEV catalog.

Do: Upgrade Curiosity Workspace to the latest vendor-supplied release and consult the vendor advisory for the specific fixed version, since none is stated in the data currently available. Audit existing access groups for memberships or administrator additions that occurred without a corresponding invitation or approval, and remove any unauthorized entries. Until patched, restrict which accounts hold non-guest status and monitor group-enrollment activity for anomalous self-joins.

Advantech's EKI-1242EIMS edge gateway, in firmware version V1.06.01, contains an OS command injection flaw (CWE-78) in its edgserver management service. A remote, unauthenticated attacker can send specially crafted requests to TCP port 5058 to inject and execute arbitrary operating system commands on the device. Because the injected commands run with root privileges, a successful exploit gives the attacker full control of the gateway, which is typically positioned to bridge IT and OT/industrial network segments. Any deployed EKI-1242EIMS running firmware V1.06.01 is affected, particularly units where port 5058 is reachable from untrusted networks. No exploitation in the wild, public proof-of-concept code, or KEV listing is known as of this analysis.

Do: Check deployed EKI-1242EIMS devices and upgrade to a firmware version newer than V1.06.01 as soon as Advantech publishes a fix. In the meantime, restrict access to TCP port 5058 with firewall/ACL rules so only trusted management hosts can reach it, and review logs for unexpected connections to that port. Treat any gateway exposed to the internet on port 5058 as high priority to remediate, given the pre-authentication, root-level nature of the flaw.

CVE-2026-73175 is an uncontrolled resource consumption flaw (CWE-400) in the OPC UA gateway component of the Advantech EKI-1242EIMS industrial gateway, confirmed in firmware version V1.06.01. An adjacent (same network segment) unauthenticated attacker can open multiple anonymous OPC UA sessions, exhausting the device's server session pool. Once the pool is exhausted, all legitimate OPC UA clients are denied service, resulting in a complete availability impact with no confidentiality or integrity impact (CVSS 4.0: 7.1 High). Operators of EKI-1242EIMS gateways in industrial and OT networks are affected, particularly where flat or poorly segmented networks allow adjacent devices to reach the OPC UA service. No public proof-of-concept is known, the flaw is not in CISA KEV, and there is no evidence of exploitation in the wild.

Do: Check the installed firmware version on EKI-1242EIMS units and upgrade to a fixed release from Advantech as soon as one is published (no fixed version is identified in the advisory). Until patching, restrict access to the gateway's OPC UA interface to trusted clients on the OT network segment, disable or limit anonymous sessions where the configuration allows, and segment the network so unauthenticated adjacent devices cannot reach the device. Monitor for abnormal session creation or gateway unavailability.

Advantech's EKI-1242EIMS edge device transmits its edgserver management protocol data without encryption (CWE-319), as identified by Nozomi Networks Labs in firmware V1.06.01. A network-adjacent attacker can passively observe this traffic—no active exploitation, privileges, or user interaction are required. By sniffing the cleartext management traffic, the attacker recovers sensitive device identity information and network metadata, which can support reconnaissance and follow-on attacks against the OT environment. Any deployment running EKI-1242EIMS firmware V1.06.01 where management traffic crosses network segments an attacker can observe is affected. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known at this time.

Do: Check deployed EKI-1242EIMS units for firmware V1.06.01 and monitor the Advantech security advisory and product pages for a fixed firmware release before upgrading. Until a fix is available, limit exposure by segmenting management traffic away from attacker-reachable network segments, restricting L2 adjacency, and carrying edgserver traffic over an encrypted tunnel or out-of-band management network. Review network monitoring for any passive sniffing indicators on segments hosting these devices.

The edgserver management protocol of the Advantech EKI-1242EIMS firmware version V1.06.01 performs no authentication for critical device-management functions (CWE-306). A remote, unauthenticated attacker can trigger these functions simply by sending crafted requests to TCP port 5058, gaining the ability to reconfigure the device's network settings, reboot or factory-reset it, and push a firmware upgrade. This effectively gives an attacker full administrative control over the device without any credentials, enabling denial of service, disruption of the network path the gateway manages, and potential implantation of malicious firmware. Any organization running the EKI-1242EIMS on the affected firmware is exposed, particularly where TCP port 5058 is reachable from untrusted networks. As of publication there is no evidence of exploitation in the wild, the issue is not in CISA's KEV catalog, and no public proof-of-concept is known; the flaw was identified by Nozomi Networks Labs.

Do: Inventory for EKI-1242EIMS devices and verify the firmware version, treating V1.06.01 as vulnerable. Immediately restrict access to TCP port 5058 with firewall rules or ACLs so only trusted management hosts can reach it, and never expose this port to the internet or flat IT networks. Contact Advantech for a patched firmware release and apply it as soon as available; until then, monitor the device for unexpected reboots, configuration changes, or firmware updates.

Advantech EKI-1242EIMS industrial gateway firmware V1.06.01 contains an external control of file name or path flaw (CWE-73) in its backup-restore workflow, discovered by Nozomi Networks Labs. A remote attacker who already holds high-privileged (administrative) credentials can upload a crafted backup archive through the web management interface, with the archive's internal file paths not properly validated. This lets the attacker overwrite arbitrary files on the device filesystem, which the CVSS 4.0 score of 8.6 (high) reflects as high impact on the confidentiality, integrity, and availability of the device, potentially enabling persistent compromise or denial of service of the gateway. Only deployments of the EKI-1242EIMS running the affected firmware with the web interface reachable are exposed, and exploitation requires valid administrative credentials. As of now, the flaw is not in CISA's KEV catalog, no public proof-of-concept is known, and no exploitation has been reported.

Do: Restrict access to the EKI-1242EIMS web management interface to trusted management networks via firewalling or VLAN segmentation, and enforce strong, unique administrative credentials since valid high-privileged access is required to exploit this flaw. Monitor Advantech's product security advisories and upgrade to a fixed firmware release when one is published, as no fixed version is identified in the current data. Check logs for unexpected backup/restore operations and verify the integrity of files on affected devices.

Advantech EKI-1242EIMS firmware version V1.06.01 contains a CWE-94 code injection flaw in the device's Modbus CSV import workflow. An attacker who holds valid, high-privileged credentials can upload a crafted CSV file through the import function, causing the gateway to execute arbitrary Lua code embedded in the file. Successful exploitation yields full confidentiality, integrity, and availability impact on the device, meaning an attacker could take control of the gateway and potentially manipulate the Modbus communications it brokers in an industrial network. Any deployment of EKI-1242EIMS running V1.06.01 with users who can access the CSV import feature is affected, with the practical barrier being the need for an authenticated account. As of now, the vulnerability is not in CISA's KEV catalog, no public proof-of-concept is known, and no exploitation has been observed in the wild.

Do: Check with Advantech for a firmware release newer than V1.06.01 that addresses the Modbus CSV import code injection and apply it when available. Until then, restrict the device's management interface to trusted administrative users on a segmented OT network, never expose the gateway directly to the internet, and audit accounts that can perform CSV imports. Nozomi Networks Labs' advisory is the source for details; monitor OT traffic for unexpected Lua/script-related device behavior.

Nozomi Networks Labs identified a CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in the Modbus transaction management interface of Advantech EKI-1242EIMS in firmware version V1.06.01 that allows a remote authenticated attacker to store malicious script content that executes in the browser of any administrator who later opens an affected management page.

CVE-2026-19535 is a Cross-Site Request Forgery (CWE-352) flaw in the LuCI administrative web interface of the Advantech EKI-1242IEIMS running firmware V1.06.01, identified by Nozomi Networks Labs. A remote unauthenticated attacker can trigger it by inducing the browser of a logged-in administrator to submit unauthorized state-changing requests to the device's management interface, typically via a malicious page or link visited while the admin session is active. Successful exploitation grants the attacker the ability to invoke privileged management functions as the administrator, which per the CVSS 4.0 score (8.6 High) can compromise the confidentiality, integrity, and availability of the device. Only operators of the Advantech EKI-1242IEIMS running the affected firmware are exposed, and the attack requires user interaction from an authenticated administrator. As of this analysis, the issue is not listed in CISA KEV, no public proof-of-concept is known, and no in-the-wild exploitation has been reported.

Do: Contact Advantech or check its support portal for a firmware release that fixes this CSRF issue, as no fixed version is specified in the available data. Until patched, restrict access to the LuCI management interface to trusted OT network segments or VPN (block direct internet exposure), and have administrators close LuCI sessions before browsing untrusted websites. Review device configuration logs for unexpected or unauthorized management changes.

The WP Mega Menu plugin by Themeum fails to properly neutralize special elements in an SQL command, allowing blind SQL injection (CWE-89) in all versions through 1.4.2. Per the CVSS vector, exploitation requires a network-accessible attacker who already holds high privileges on the WordPress site (e.g., an administrator account), with no user interaction and low attack complexity. Through blind injection, an attacker can extract arbitrary data from the site database character by character, potentially exposing user credentials, password hashes, and other sensitive information, with minor availability impact. Any WordPress site running WP Mega Menu at version 1.4.2 or earlier is affected. No public proof-of-concept, listings in CISA's KEV catalog, or reports of in-the-wild exploitation are currently known.

Do: Update WP Mega Menu to the latest release (any version newer than 1.4.2 once available from Themeum/WordPress.org), or deactivate the plugin until a patched version is published. Restrict and audit administrator-level accounts, since the flaw requires high-privilege access to trigger, and monitor Patchstack's advisory for the fixed version details. Check plugin versions across your WordPress estate (e.g., via WP-CLI or a vulnerability scanner) to confirm no site is running 1.4.2 or earlier.

yshop-crm through 2.1.3 fails to enforce authorization on the GET /admin-api/system/user/page endpoint because the @PreAuthorize permission annotation is commented out (CWE-862, missing authorization). To exploit it, an attacker needs valid back-office credentials and a role assigned a data scope of ALL, but does not need the system:user:list permission that the endpoint is supposed to require. A successful attacker can retrieve the complete user directory, including login names, nicknames, departments, email addresses, mobile numbers, and last-login information — useful for follow-on phishing, credential attacks, or social engineering. Any deployment of yshop-crm at version 2.1.3 or earlier is affected. No exploitation has been reported, no public proof-of-concept is known, and the issue is not in CISA KEV; it carries a CVSS 4.0 score of 7.1 (high).

Do: Upgrade to a release in which the @PreAuthorize permission check on /admin-api/system/user/page is restored (no fixed version is specified in the data); as an interim measure, re-enable the authorization annotation or block/limit access to the endpoint at a gateway. Review roles configured with data scope ALL and least-privilege back-office accounts, and audit access logs for unexplained calls to /admin-api/system/user/page.

yshop-crm through version 2.1.3 contains a missing authorization flaw (CWE-862) in the CrmFlowController deleteFlowStep function. Any authenticated back-office user, regardless of assigned permissions, can invoke DELETE /admin-api/crm/flow/delete-step to delete arbitrary approval workflow steps. Because those steps gate the finalization of contracts, receivables, and invoices, an attacker can weaken or disable approval controls and push records through finalization without proper review, or disrupt the approval process entirely. Any organization running a self-hosted yshop-crm instance at version 2.1.3 or earlier is affected. No public proof-of-concept exists, the flaw is not in CISA's KEV catalog, and no exploitation is currently known.

Do: Upgrade yshop-crm to a release newer than 2.1.3 that restores the permission check on the deleteFlowStep endpoint as soon as one is published. Until then, restrict access to /admin-api/crm/flow/delete-step at the reverse proxy or gateway layer to roles that genuinely require it, and review approval workflow step configurations for unexplained deletions. Audit back-office account activity and API logs for DELETE requests to this endpoint to detect potential abuse.

yshop-crm through 2.1.3 contains a missing authorization vulnerability in the GET /admin-api/crm/flow/flow-users endpoint that allows any logged-in back-office user to access approval workflow data. Attackers can retrieve approval chain topology, step ordering, approver identifiers, and personal information including login names, nicknames, departments, email addresses, mobile numbers and last login IP addresses.

yshop-crm through 2.1.3 fails to enforce authorization (CWE-862) on the GET /admin-api/crm/operatelog/page endpoint, which serves the installation-wide operation/audit log. Any user with even low-privilege authenticated access to the back-office API can call this endpoint over the network without administrator rights. By doing so, the attacker obtains operator account names, display nicknames, client IP addresses, User-Agent strings, request URLs, action details, and customer identifiers — useful intelligence for further attacks, internal recon, or targeted phishing. Any organization running a self-hosted yshop-crm instance at version 2.1.3 or earlier is affected. No public proof-of-conct has been released, the issue is not in CISA KEV, and no in-the-wild exploitation is confirmed; CVSS 4.0 scores it 7.1 (High) with high confidentiality impact.

Do: Upgrade yshop-crm to a release newer than 2.1.3 as soon as a patched version incorporating an authorization check on the operatelog/page endpoint is available. Until then, restrict network access to the /admin-api/ surface (reverse-proxy ACL or VPN), and audit web-server logs for calls to /admin-api/crm/operatelog/page by non-administrator accounts, which would indicate abuse. Review back-office role assignments to minimize how many low-privilege users can reach admin-api endpoints.

yshop-crm through version 2.1.3 contains a missing authorization flaw (CWE-862) in the CrmCluesController receiveCustomer endpoint, which is used to claim sales leads. Any authenticated back-office user can invoke this endpoint without the permission check it should enforce, overwriting the ownerUserId field to reassign leads that belong to other employees to themselves. Because the endpoint performs no access logging and no quota validation, an attacker with even low-level credentials can silently siphon large volumes of leads in bulk, damaging the integrity of the sales pipeline. Any organization running yshop-crm up to and including 2.1.3 is affected. No public proof-of-concept is known and the flaw is not in CISA's KEV, so exploitation has not been confirmed in the wild.

Do: Upgrade yshop-crm to a version patched for CVE-2026-92459 when the vendor releases one (no fixed version is specified in current disclosures); meanwhile, restrict which back-office roles can reach the CrmCluesController receiveCustomer endpoint, e.g., via a gateway or WAF rule. Audit lead records for ownerUserId changes that no legitimate user action explains, and review which low-privilege accounts hold back-office credentials that could reach the endpoint.

yshop-crm through 2.1.3 contains a missing authorization vulnerability in the StoreProductController onSale handler that allows authenticated back-office users to modify product sale status. Attackers can invoke the GET /admin-api/product/store-product/sale endpoint with sequential product IDs to withdraw entire product catalogs from sale or re-enable withdrawn products without proper permission checks.

yshop-crm through 2.1.3 fails to enforce a permission check on the CrmInvoiceController issueInvoice endpoint, a classic CWE-862 missing authorization flaw. Any authenticated back-office user, regardless of assigned role, can call PUT /admin-api/crm/invoice/issue and perform invoice issuance actions that should require elevated permissions. By exploiting this, an attacker can modify invoice status, inflate contract invoiced amounts with arbitrary attacker-chosen values, and trigger invoice emails to arbitrary addresses, enabling financial-record manipulation and possible fraud or phishing via spoofed invoice emails. All deployments of yshop-crm up to and including version 2.1.3 are affected. No public proof-of-concept or confirmed in-the-wild exploitation is known at this time.

Do: Upgrade yshop-crm to a release newer than 2.1.3 as soon as a patched version is available. As interim mitigation, restrict access to the /admin-api/crm/invoice/issue endpoint (e.g., via a gateway or WAF rule) and audit back-office accounts for over-broad access. Review existing invoice records and contract invoiced amounts for tampering and check email logs for unexpected invoice issuances or messages sent to unknown addresses.

yshop-crm through version 2.1.3 fails to enforce authorization (CWE-862) on the saveRedisSet and getRedisSet endpoints in CrmCustomerController, leaving installation-wide lead-allocation and customer auto-recycling settings unprotected. Any authenticated back-office user, regardless of assigned role or permissions, can invoke these network-reachable endpoints to read and overwrite the shared Redis keys that drive customer auto-recycling behavior. By manipulating those keys, an attacker can trigger mass deletion of customer data, disable lead recycling entirely, or block creation of new customers across the whole deployment. All yshop-crm deployments at version 2.1.3 or earlier that have low-privilege back-office accounts are affected. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known; the flaw carries a CVSS 4.0 score of 7.1 (high).

Do: Upgrade to a fixed release newer than 2.1.3 as soon as the vendor publishes one, and track the project repository for the patch. As an interim mitigation, block or restrict access to the saveRedisSet and getRedisSet endpoints in CrmCustomerController at the reverse proxy or WAF, and audit shared Redis keys for unauthorized changes to recycling policy. Review back-office account lists and remove or downgrade low-privilege users who do not need CRM access.

yshop-crm through 2.1.3 fails to enforce authorization on the sendSms and sendMail endpoints in CrmCustomerController, allowing any authenticated back-office user to send SMS and email to arbitrary customers. Attackers can invoke POST /admin-api/crm/customer/send-sms and POST /admin-api/crm/customer/send-mail with arbitrary customerIds, templateCode, and templateParams to deliver unauthorized messages through the organization's SMS and email channels.

WNC's T-Mobile 5G Box IDU router contains an OS command injection flaw (CWE-78) in the portal.cgi component's password change functionality. The web application fails to properly neutralize special characters in the http_passwd_hidden and http_passwdConfirm_hidden parameters, allowing submitted values to be interpreted as operating system commands. An attacker who is already authenticated to the router's management portal (CVSS 4.0 rates privileges required as high, with adjacent-network attack vector) can leverage this to execute arbitrary commands with root privileges on the device's underlying OS. Any subscriber or operator running affected firmware on this gateway is exposed, primarily to attackers on the local network or connected clients. No exploitation in the wild, public proof-of-concept, or KEV listing is currently known, and a fixed firmware version (1.1.0.651412) has been released.

Do: Upgrade the gateway to firmware version 1.1.0.651412 or later, checking the current version in the router's admin portal. Restrict management-portal access to trusted LAN clients, ensure strong non-default admin credentials are set, and monitor for client compromise, since exploitation requires valid portal authentication from an adjacent network.

The WNC T-Mobile 5G Box IDU router contains an unauthenticated OS command injection flaw (CWE-78) in its /cgi-bin/portal.cgi web portal endpoint. The cli_cookie POST parameter is concatenated directly into a shell find command without sanitization, so a crafted POST request allows an attacker to append and execute arbitrary shell commands. Successful exploitation yields command execution as root on the underlying operating system, giving full control of the gateway and the traffic it handles. Per the CVSS 4.0 vector (AV:A), exploitation requires an attacker positioned on the network adjacent to the router, such as a device on its Wi-Fi or LAN, with no credentials or user interaction needed. All firmware prior to 1.1.0.651412 is affected; no public proof-of-concept, KEV listing, or confirmed in-the-wild exploitation is currently known.

Do: Upgrade the router to firmware version 1.1.0.651412 or later. Until updated, do not expose the management portal (/cgi-bin/portal.cgi) to the WAN and restrict LAN/Wi-Fi access to trusted devices. Check device logs for unexpected POST requests to /cgi-bin/portal.cgi containing a cli_cookie parameter, which may indicate exploitation attempts.

The WNC T-Mobile 5G Box IDU router contains a cross-site request forgery (CWE-352) flaw in its portal.cgi component: the anti-CSRF mechanism fails to actually validate the csrf_token_value parameter, so any arbitrary token value is accepted as valid. An attacker exploits this by luring an already-authenticated user (e.g., someone logged into the router's admin portal) into visiting a malicious website, whose pages silently submit forged requests to the gateway over the local network. Because the CSRF check is effectively bypassed, the attacker can perform unauthorized actions on the device with the victim's session, such as changing device settings — reflected in the CVSS 4.0 score of 8.4 with high confidentiality and integrity impact and a requirement for user interaction. All users of this T-Mobile-branded router running firmware older than 1.1.0.651412 are affected. No exploitation has been reported in the wild, no public proof-of-concept is known, and the flaw is not listed in CISA's KEV catalog.

Do: Upgrade the router to firmware version 1.1.0.651412 or later, available through the device's update mechanism or T-Mobile support. Until updated, avoid clicking links in unsolicited emails or websites while connected to the gateway's network, and review device settings (DNS servers, admin credentials, port forwarding) for unexpected changes.

The WNC T-Mobile 5G Box IDU router has an improper access control flaw (CWE-306): the wnc_maccheck.cgi endpoint can be reached without any authentication. An unauthenticated attacker on an adjacent network (per the CVSS 4.0 attack vector, e.g., the same LAN or Wi-Fi segment) can query this endpoint and pull sensitive configuration data. The disclosed data includes the administrator web password, the Wi-Fi passphrase, and technical device information, potentially allowing takeover of router administration or access to the wireless network. All users of this router running firmware older than 1.1.0.651412 are affected. No public proof-of-concept, KEV listing, or confirmed in-the-wild exploitation is known.

Do: Upgrade the router to firmware version 1.1.0.651412 or later via the device's firmware update mechanism. Until patched, restrict the management interface to a trusted LAN segment and confirm remote/WAN administration is disabled. Because the admin password and Wi-Fi passphrase are recoverable by local attackers, rotate both credentials after updating if untrusted devices may have had local network access.

The WNC-manufactured T-Mobile 5G Box IDU router contains a command injection flaw (CWE-78) in the ping functionality of its /cgi-bin/portal.cgi web endpoint. The ping_ip, ping_size, and ping_times POST parameters are incorporated into a system command without verification or sanitization, allowing an attacker to append arbitrary shell commands. Because the CVSS vector requires adjacent-network access and high privileges, an attacker needs valid credentials on the router's portal interface, but once authenticated they can execute arbitrary commands and gain root access, fully compromising the gateway. All units running firmware before 1.1.0.651412 are affected, and a fixed firmware is available. No public proof-of-concept is known, the issue is not in CISA's KEV, and no in-the-wild exploitation has been confirmed.

Do: Upgrade the router to firmware 1.1.0.651412 or later via the admin portal or carrier-pushed updates, and verify the running version in the web interface. Because exploitation requires portal credentials, set a strong admin password, keep remote/WAN management of the portal disabled, and limit admin access to trusted LAN clients.

The WNC T-Mobile 5G Box IDU router contains an authentication bypass (CWE-290) in its portal.cgi component, where session verification only checks that a file matching the sessionid cookie value exists under /tmp/login_user. Because that check can be satisfied with directory entries such as '.' or '..', an unauthenticated attacker can forge a cookie value that passes validation. Successful bypass grants unauthorized access to the router's administration panel, where high-impact configuration and control actions are possible (CVSS 4.0 rates confidentiality, integrity, and availability impact as high). The attack vector is adjacent (AV:A), meaning the attacker must already be on the local network, such as a Wi-Fi or LAN client. No public proof-of-concept, in-the-wild exploitation, or KEV listing is known; affected users should move to firmware 1.1.0.651412 or later.

Do: Upgrade the router to firmware 1.1.0.651412 or later and verify the installed version in the administration panel. Because exploitation requires adjacent network access, avoid connecting untrusted devices to the router's LAN/guest networks until updated, and confirm the administration interface is not reachable from the WAN side.

A vulnerability was identified in a2ui-project a2ui 0.8/0.9/1.0. Impacted is an unknown function of the file model-processor.ts of the component Model Processor. The manipulation of the argument current[segment] leads to information disclosure. The attack may be initiated remotely. The identifier of the patch is 1b3bff234661ce922cbc3771be642b23ec9fd0fa. To fix this issue, it is recommended to deploy a patch.

A vulnerability was determined in a2ui-project a2ui 0.9/0.9.1. This issue affects the function updateComponents of the file basic_functions.ts of the component Update Components. Executing a manipulation can lead to resource consumption. The attack can be launched remotely. The project was informed of the problem early through an issue report but has not responded yet.

In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers.

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() ni_create_attr_list() allocates a fixed buffer of al_aligned(record_size) (== record_size) bytes and then walks every attribute of the primary MFT record, writing one ATTR_LIST_ENTRY per attribute and advancing the cursor by le_size(name_len), with no check against the end of the buffer; the total size is only computed after the loop. A minimum-size resident attribute occupies SIZEOF_RESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to le_size(0) (0x20 = 32) bytes in the list. Because the number of attributes in a record is not bounded (mi_enum_attr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than record_size and overflows the heap buffer. This is reachable from a crafted, loop-mounted NTFS image: opening the file and adding an attribute (e.g. via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list(). BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0xc48/0x1058 Write of size 4 at addr ffff000008984c00 by task setfattr/345 ni_create_attr_list+0xc48/0x1058 ni_ins_attr_ext+0x510/0x7c0 ni_insert_attr+0x3f8/0x70c ni_insert_resident+0xc8/0x3b0 ntfs_set_ea+0x66c/0xd28 ntfs_setxattr+0x4d8/0x5b0 __arm64_sys_setxattr+0xa4/0x124 Allocated by task 345: ni_create_attr_list+0x188/0x1058 The buggy address belongs to the cache kmalloc-1k of size 1024 (the write lands at object+1024). Size the buffer from the actual attributes instead of assuming a single record_size is always enough.

In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don't hand out the flat CCS storage as usable VRAM get_flat_ccs_offset() reads the base of the flat CCS storage from the hardware, scales it by the number of enabled L3 nodes, and rounds the result up to 128K. Everything below that offset is then handed to the VRAM allocator as usable memory. Rounding a limit that means "usable memory ends here" upwards publishes whatever lies between the real base and the rounded one as free memory, and that memory belongs to the compression hardware. The scaled value has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it is not: flat CCS base: raw 0x3fafff800, rounded 0x3fb000000 so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator's pool. Whatever is allocated there gets that tail overwritten by the compression hardware, which needs no page-table entry, no buffer object and no GPU submission to do it, and does it before userspace exists. On this machine a Mesa VM's level-3 page table landed on that page on every cold boot. It lost the entry covering the compositor's batch-buffer heap, so the compositor's first submission faulted fetching its batch and gdm restarted it forever: a black screen on an otherwise working machine. Restarting gdm cleared it because the next VM's page tables were allocated somewhere else. Round down instead, to the page size the allocator works in. On this machine that excludes exactly one page. Reading the reserved page afterwards shows what had been writing it: [369] 0xcccc000000000000 [371] 0xcc77000000000000 [373] 0xcccc000000000000 [375] 0xcc77000000000000 compression metadata, two bytes per sixteen, sitting where the driver used to hand out memory. The assertion that should have caught this compares the offset against GSMBASE - ccs_size for equality. That value is 128K aligned, so it agrees with the rounded-up offset precisely when the base is not aligned - the check cannot fail in the case it exists to catch, and is compiled out unless CONFIG_DRM_XE_DEBUG is set. Replace it with one that can fail: CCS storage must not run into GSM. [ And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work. I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it. I suspect those things have been trained by people who may not be quite as stubborn as I am. But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above. This is basically a one-liner fixing a bogus "round_up()" to a "round_down()", but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this. - Linus ]

In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: don't spin_trylock() in NMI on UP Patch series "mm/page_alloc: fixes for free_pages_nolock() on RT/UP". Pre-existing bugs found by Sashiko during review of this other series: https://lore.kernel.org/all/[email protected]/ I have not reproduced these bugs, and I suspect there is no real-world user that is affected by them. This patch (of 2): As noted in can_spin_trylock(), using this is unsafe in this context. commit 620b46ed6ae17 ("mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP") fixed this on the alloc side but missed the free side. Impact: If BPF programs using these features in NMI (probably tracing) are present on non-SMP builds this might crash the kernel and is probably exploitable by local attackers for privilege escalation.

In the Linux kernel, the following vulnerability has been resolved: USB: gadget: ffs: fix mm lifetime handling io_data stores a pointer to the submitting task's mm_struct, but does not currently hold a reference to it while async requests are pending. This can result in a use-after-free if the task exits before completion handling finishes. Take a reference with mmgrab() when queuing the read request and release it with mmdrop() on request completion.

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix Use-After-Free in AIO error path In ffs_epfile_write_iter() and ffs_epfile_read_iter(), when ffs_epfile_io() fails with an error other than -EIOCBQUEUED, the io_data structure (`p`) is freed. However, for AIO operations, the kiocb cancel function was already armed and kiocb->private was set to `p`. If a concurrent cancel operation (such as sys_io_cancel()) executes after ffs_epfile_io() fails but before the function frees `p`, a Use-After-Free can occur when the cancellation handler accesses the freed pointer. To securely fix this race condition, we must properly un-arm the cancellation. Invoking `kiocb->ki_complete()` does exactly this by acquiring `ctx->ctx_lock` and safely removing the kiocb from the active sequence. In doing so, it ensures that a parallel io_cancel can no longer discover the kiocb, effectively closing the race window. We then return -EIOCBQUEUED to notify the VFS layer that the kiocb has been consumed and it should avoid attempting to complete the request again or triggering subsequent completion handlers.

In the Linux kernel, the following vulnerability has been resolved: zram: fix slot lock bit position on big-endian 64-bit The slot lock is a bit operation on the whole __lock word, which flags and ac_time alias as two u32s. On little-endian the lock bit lands in the position ZRAM_ENTRY_LOCK reserves in flags, so the aliasing works out. On 64-bit big-endian it lands in ac_time instead: with ZRAM_TRACK_ENTRY_ACTIME enabled, storing the access time from mark_slot_accessed() or slot_free() wipes out the held lock bit, letting another CPU take the same slot lock; an access time value with that bit set makes the slot look locked forever. Shift the lock bit into the flags half of the word on big-endian 64-bit.

In the Linux kernel, the following vulnerability has been resolved: ceph: properly decrypt filenames in vmalloc() buffers The fscrypt subsystem uses the scatterlist crypto API, inheriting its requirement that any buffers are in the linear mapping region. However, the messenger client uses kvmalloc() to create buffers for messages, which will occasionally place those buffers in the vmalloc() region when physical memory fragmentation doesn't permit a large enough kmalloc(). The various callers of ceph_fname_to_usr() directly pass (slices of) raw messages from the MDS without considering that the messages may be in vmalloc() buffers, resulting in oopses especially on non-x86 platforms (see 'Closes:' for more details and a reproducer). Make ceph_fname_to_usr() explicitly tolerant of vmalloc()-allocated fname->ctext, fname->name, and/or oname->name buffers, using `tname` (which, when non-null, must be a linear address; when null, is briefly allocated as necessary) as a bounce buffer to avoid passing any inappropriate addresses to fscrypt_fname_disk_to_usr(). Additionally change parse_reply_info_readdir() -- the only function to supply its own `tname` -- to follow the new "tname must never come from vmalloc()" rule by passing NULL when the message is not in the linear region. Though this causes a per-dentry kmalloc()+kfree(), this overhead exists only when processing the minority of messages that spill into vmalloc(). My (crude) testing puts this at only about 1 in 8,000 readdir messages. Still, if the overhead proves unreasonable in the future, it is easy enough to mitigate: a future change could allocate a bounce buffer in parse_reply_info_readdir() and use that as `tname` instead.

In the Linux kernel, the following vulnerability has been resolved: HID: sony: clean up device list on probe failure sony_input_configured() adds some controllers to sony_device_list before HID core registers their input devices. input_register_device() can fail after the callback returns successfully. sony_probe() then observes that HID_CLAIMED_INPUT is clear and unwinds, but only stops the HID hardware. The devres-managed sony_sc is freed while its list node remains linked, so the next matching controller traverses freed memory. Initialize the list node and device ID to inactive states. Make list removal idempotent and run the driver-private cleanup on every probe failure path. This also makes a second cleanup safe when sony_input_configured() already unwound a partial initialization before sony_probe() handles the missing input claim. Found by 0sec (https://0sec.ai) using automated source analysis; verified against the HID input registration and probe unwind paths.

In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the "outer" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e irq event stamp: 20689 hardirqs last enabled at (20699): [ ] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [ ] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [ ] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [ ] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99 ---truncated---

In the Linux kernel, the following vulnerability has been resolved: NFSD: Guard admin state-revocation walks with NFSD_NET_UP Writing to /proc/fs/nfsd/unlock_filesystem, or sending the NFSD_CMD_UNLOCK_FILESYSTEM or NFSD_CMD_UNLOCK_EXPORT netlink command, walks the NFSv4 client hash tables to revoke open state and cancel async COPY operations. All three handlers gate that walk on nn->nfsd_serv, but a listener added via portlist or netlink listener_set sets nn->nfsd_serv before any nfsd thread starts. nfsd_startup_net() has not yet allocated nn->conf_id_hashtbl, so the walkers dereference a NULL table. A local administrator with CAP_SYS_ADMIN can crash the kernel this way without ever starting the server. nn->nfsd_serv is set when the service is created, which precedes table allocation. NFSD_NET_UP instead brackets the window where the tables are live: set at the end of nfsd_startup_net() and cleared in nfsd_shutdown_net() after they are freed, both under nfsd_mutex. Gating the three unlock paths on NFSD_NET_UP fixes the startup-time NULL dereference while preserving the earlier post-shutdown use-after-free fix.

In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during export state revocation nfsd4_revoke_export_states() has the same use-after-free as nfsd4_revoke_states(): it drops nn->client_lock across revoke_one_stid() and the following read of clp->cl_minorversion, but the stateid reference it holds does not pin the client. A teardown racing the dropped lock can free the client while revoke_one_stid() still dereferences it. exportfs -u drives this path through NFSD_CMD_UNLOCK_EXPORT, so an administrator removing an export can race a client expiry. Skip a client that is already expiring and otherwise pin it with cl_rpc_users under client_lock before dropping the lock, matching nfsd4_revoke_states().

In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during close_lru reaping An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock. Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat.