Vulnerabilities

ISC's BIND 9 DNS server contains a resource-exhaustion flaw (CWE-407) in which a recursive resolver consumes excessive CPU and memory when it encounters large numbers of a particular kind of invalid DNSSEC record. A remote, unauthenticated attacker can trigger this by causing a BIND resolver to process attacker-influenced DNSSEC data — for example, by having the resolver look up names served from authoritative servers that return the malformed records — degrading or halting DNS resolution (availability impact only, per the CVSS vector). Any organization operating a BIND recursive resolver in the affected version ranges is exposed, including internet-facing open resolvers and internal enterprise, campus, and ISP resolvers; ISC notes that default settings of the 'max-records-per-type' and 'max-types-per-name' limits help mitigate the exposure. There is no public proof-of-concept, the flaw is not in CISA KEV, and no in-the-wild exploitation is known; it was disclosed by ISC as one of fourteen BIND 9 vulnerabilities.

Do: Inventory all BIND 9 recursive resolvers (recursion enabled) and upgrade them to the first patched release in their branch per ISC's advisory for CVE-2026-19668 — i.e., versions newer than the affected ranges 9.11.0–9.18.50, 9.20.0–9.20.27, 9.21.0–9.21.25, 9.11.3-S1–9.18.50-S1, and 9.20.9-S1–9.20.27-S1 (or the corresponding newer Subscription builds). Until patched, keep the default 'max-records-per-type' and 'max-types-per-name' limits in place (do not raise them) and restrict recursion to trusted client networks via allow-recursion ACLs, prioritizing resolvers that are internet-reachable or resolve external names.

CVE-2026-19666 is a use-after-free flaw (CWE-416) in the DNS64 processing path of ISC's BIND 9 DNS server. On a recursive resolver ('named') configured with dns64, receiving an applicable answer from an authoritative server that is malformed in a specific way causes the named process to exit unexpectedly. An unauthenticated remote attacker can therefore crash the resolver, achieving a denial of service with high availability impact but no confidentiality or integrity impact (CVSS 3.1: 7.5, AV:N/AC:L/PR:N/UI:N). Only operators running the listed BIND 9 versions with dns64 enabled are affected; resolvers without dns64 configured are not impacted by this flaw. There is no known public proof-of-concept and the vulnerability is not on the CISA KEV list, though it was disclosed as one of fourteen BIND 9 issues by ISC.

Do: Upgrade affected BIND 9 resolvers to a patched release beyond the listed version ranges as soon as ISC's updated builds are available, prioritizing recursively-serving resolvers with dns64 configured. As an interim mitigation, remove or comment out the dns64 block in named.conf if IPv6 translation is not required, and restrict recursion to trusted client networks. Verify exposure by checking named.conf (or included files) for dns64 directives.

In ISC BIND 9, a secondary server that restricts zone transfers with TSIG may begin serving data from an incoming multi-message TCP IXFR before the final message carrying the TSIG signature arrives, and it never rolls back to the pre-transfer state if that signature never arrives (CWE-349, acceptance of extraneous untrusted data). An attacker who does not possess a valid TSIG key but can impersonate the zone's primary on the transfer path (e.g., via a spoofed or man-in-the-middle transfer session) can send unauthorized zone contents, which the secondary then serves to clients. The impact is loss of DNS data integrity with limited availability impact and no confidentiality impact (CVSS 6.5, network vector with high attack complexity). Any BIND 9 deployment in the affected version ranges configured as a secondary zone with TSIG-restricted transfers is affected, and the transfer must be a multi-message TCP IXFR as described by RFC 8945. No exploitation in the wild, public proof-of-concept, or CISA KEV listing is known; ISC disclosed this flaw as one of fourteen BIND 9 vulnerabilities.

Do: Upgrade BIND 9 to the fixed releases from ISC's advisory, i.e., versions later than 9.18.50, 9.20.27, or 9.21.25 (or the matching -S1 builds) depending on the branch in use. As interim mitigations on secondaries, disable incremental transfers to primaries (request-ixfr no; in named.conf, since the flaw requires a multi-message TCP IXFR) and layer source-address restrictions (allow-notify / primaries ACLs) on top of TSIG so only the genuine primary can initiate updates. Audit named.conf for secondary zones whose transfer protection relies solely on TSIG keys.

CVE-2026-18212 is a memory leak (CWE-401) in the SAML Redirect Binding implementation of Keycloak, Red Hat's open-source identity and access management solution: the custom DEFLATE compression and decompression helpers allocate native zlib memory but never release it. An unauthenticated remote attacker can trigger the leak by sending repeated malformed SAML requests that exercise the Redirect Binding DEFLATE path. Because the leaked memory is native (outside the JVM heap), accumulation eventually exhausts process memory and causes a denial of service, despite the attacker gaining no code execution or data access. Any Keycloak deployment (including Red Hat Single Sign-On derivatives) that accepts SAML Redirect Binding requests is affected. Exploitation has not been observed in the wild, no proof-of-concept is public, and the flaw is not in the CISA KEV catalog.

Do: Upgrade Keycloak (and Red Hat Single Sign-On derivatives) to the patched release named in the Red Hat security advisory for CVE-2026-18212, as no fixed version is specified in the data available here. Until patched, limit internet exposure of Keycloak/SAML endpoints (VPN, allowlisting, or WAF rate-limiting on SAML request paths) and monitor native process memory for abnormal growth, restarting instances that show sustained leaks. Confirm whether your realms use SAML Redirect Binding, since deployments using only other bindings have reduced exposure.

Dell ECS and Dell ObjectScale use a broken or risky cryptographic algorithm (CWE-327) to protect certain data, allowing it to be decrypted or reconstructed by someone who obtains the stored output. Exploitation requires an attacker who already has high-privileged local access to the system, so it is best viewed as a privilege-escalation/information-disclosure weakness for insiders or attackers who have compromised the appliance. A successful exploit results in exposure of confidential information (confidentiality impact only; integrity and availability are unaffected). Organizations running Dell ECS versions 3.8.1.0 through 3.8.1.7 or ObjectScale versions prior to 4.4.0.0 are affected. There are currently no reports of in-the-wild exploitation, no CISA KEV listing, and no known public proof-of-concept.

Do: Upgrade ObjectScale to 4.4.0.0 or later, and upgrade ECS from the 3.8.1.x line to a fixed release per Dell's security advisory (Dell security alert DSA-2025-XXX for CVE-2025-36591). Because exploitation requires high-privileged local access, restrict administrative and shell access to ECS/ObjectScale nodes to trusted operators, and review and rotate secrets or credentials that may have been protected by the weak algorithm on affected versions.

zlt2000 microservices-platform through version 6.0.0 has an authorization bypass (CWE-639) in the file-center module's DELETE /files/{id} endpoint, which performs no validation that the requesting user owns the targeted file. Any authenticated user can first enumerate file identifiers via GET /files and then supply arbitrary identifiers to the delete endpoint, erasing other users' files and their metadata. The attack requires only low-privilege authenticated access over the network with no user interaction, resulting in high integrity and availability impact to stored file data but no confidentiality loss or system compromise. Any deployment running the file-center module of microservices-platform 6.0.0 or earlier is affected. No public proof-of-concept, CISA KEV listing, or reports of in-the-wild exploitation are currently known.

Do: No fixed version is stated in the available data, so check the vendor's repository for a patched release and apply it when available. As an interim mitigation, add an ownership check (or role-based restriction) on DELETE /files/{id}, limit which accounts can reach the file-center API, and review deletion logs for unauthorized removals of other users' files.

zlt2000 microservices-platform through version 6.0.0 contains an authorization bypass (CWE-639) in its search-center service. An authenticated attacker can supply an arbitrary Elasticsearch index name as a path variable in POST /search/{indexName} or GET /agg/requestStat/{indexName}/{routing}, and the service queries that index without verifying the caller is authorized to access it. This allows any low-privileged authenticated user to read data from any Elasticsearch index in the cluster, including the sys_user index, exposing user records and password hashes. All deployments of microservices-platform up to and including 6.0.0 are affected. There are currently no known public proofs of concept, no reports of exploitation in the wild, and the issue is not listed in CISA's KEV catalog.

Do: No fixed version is specified in the disclosure, so check the vendor's GitHub repository for a patched release and upgrade beyond 6.0.0 when available. In the meantime, restrict access to the /search/{indexName} and /agg/requestStat/ endpoints at the gateway or via WAF rules, and enforce an allowlist of index names each authenticated role may query. Because the sys_user index with password hashes is readable through this flaw, audit access logs for unexpected index queries and consider rotating user credentials on exposed deployments.

The PUT /users/password endpoint in zlt2000 microservices-platform fails to verify the current password before applying a change (CWE-620, unverified password change). An authenticated user can send a request containing an arbitrary target user id and a new password, and the platform overwrites that account's credentials without confirming the caller knows the existing password. This allows any low-privileged authenticated user to take over any non-administrator account; administrator accounts are not affected. All deployments running zlt2000 microservices-platform version 6.0.0 or earlier are affected. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is currently known.

Do: Upgrade to a release newer than 6.0.0 once a patched version is published, or add a server-side check that the caller supplies and the platform validates the current password in PUT /users/password. In the meantime, restrict network access to the users/password endpoint and review recent password-change audit logs for changes made by unexpected callers. If tampering is suspected, force a credential rotation for affected non-administrator accounts.

zlt2000 microservices-platform through 6.0.0 ships with the zlt.security.auth.urlPermission.enable flag set to false by default, which disables all URL-level permission enforcement after a user authenticates. Any authenticated account, even one with no roles assigned, can therefore call administrative APIs directly, including user management, role assignment, and Elasticsearch index operations. This lets a low-privileged or newly registered user escalate privileges (e.g., grant themselves roles), manage accounts, and manipulate Elasticsearch data. All deployments running version 6.0.0 or earlier that have not explicitly enabled the URL permission check are affected. There is currently no public proof-of-concept, no CISA KEV listing, and no known exploitation in the wild.

Do: Explicitly set zlt.security.auth.urlPermission.enable=true in all deployments instead of relying on the insecure default, and verify that administrative endpoints (user management, role assignment, Elasticsearch index operations) reject accounts without roles. Upgrade to a patched release when one becomes available, audit role assignments and recently created accounts for signs of abuse, and review application logs for admin API calls from role-less users.

A vulnerability was found in vllm-project vllm up to 0.29.0. Affected by this issue is some unknown functionality of the file vllm/v1/sample/thinking_budget_state.py. The manipulation results in inefficient algorithmic complexity. It is possible to launch the attack remotely. The pull request to fix this issue awaits acceptance.

A vulnerability has been found in itsourcecode Leave Management System 1.0. Affected by this vulnerability is an unknown functionality of the file /module/employee/index.php. The manipulation of the argument ID leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.

A flaw has been found in ag-ui-protocol ag-ui 1.0. Affected is an unknown function of the file src/stream/sse_parser.cpp of the component JSON Parser. Executing a manipulation can lead to resource consumption. The attack may be performed from remote. This patch is called ab6e0bc298996caac2b4b0b3ec0bd8d32a15a186. Applying a patch is advised to resolve this issue.

A vulnerability was detected in ag-ui-protocol ag-ui 1.0. This impacts an unknown function of the file crates/ag-ui-client/src/sse.rs of the component SSE Frame Parser. Performing a manipulation results in resource consumption. The attack is possible to be carried out remotely. The pull request to fix this issue awaits acceptance.

Jenkins Keycloak Authentication Plugin 2.4.1 and earlier does not restrict the redirect URL after login, allowing attackers to perform phishing attacks.

Jenkins Gitee Plugin 1301.v8957053c7902 and earlier does not escape the sender name from Gitee push webhook payloads in build causes, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to trigger builds via the Jenkins Gitee Plugin webhook endpoint.

Jenkins Bitbucket Push and Pull Request Plugin 4.0.1 and earlier trusts values provided in the webhook payload, including certain URLs, and uses configured Bitbucket credentials to connect to those URLs, allowing attackers to capture Bitbucket credentials stored in Jenkins by sending a crafted webhook payload.

The OAuth authorization endpoint in Jenkins Bitbucket Server Integration Plugin 6.0.1 and earlier reads the `oauth_callback` URL from the submitted form rather than from the server-side stored request token, allowing attackers to hijack the OAuth flow and obtain an access token on behalf of the victim.

The Robot Framework Plugin for Jenkins, version 6.2.2 and earlier, fails to verify that the archive directory configured for Robot Framework report files is contained within the build directory on the Jenkins controller (a path traversal flaw, CWE-22). An attacker who holds Item/Configure permission on any job can set an archive directory pointing outside the build directory and thereby create or replace arbitrary files on the controller file system with attacker-specified content. By overwriting sensitive files, the attacker can achieve remote code execution on the Jenkins controller. Any Jenkins instance running the affected plugin is exposed, particularly where Item/Configure permission is granted to broad or partially trusted user groups. No public proof-of-concept is known and the flaw is not listed in CISA's Known Exploited Vulnerabilities catalog, so exploitation has not been confirmed.

Do: Upgrade the Robot Framework Plugin to a fixed release newer than 6.2.2 as soon as it is published, and review Jenkins security advisories for the exact fixed version. Until then, restrict Item/Configure permission to fully trusted users only, and audit existing job configurations for archive directory paths that escape the build directory. Check the Jenkins controller file system for unexpected or recently modified files that could indicate abuse.

The OWASP Dependency-Check Plugin for Jenkins up to and including version 5.6.4 fails to escape CWE values taken from Dependency-Check reports before rendering them in the Jenkins UI, enabling a stored cross-site scripting (XSS) vulnerability. An attacker who already holds Item/Configure permission on a Jenkins job can inject a malicious payload into the report data so that it persists and executes whenever other users view the report in the web interface. A successful attack lets the attacker run arbitrary script in the victim's browser session, potentially hijacking sessions and performing actions with the victim's Jenkins privileges. Any Jenkins controller running the affected plugin is exposed, particularly multi-user controllers where report viewers are not the same users who configure jobs. No exploitation in the wild or public proof-of-concept is currently known.

Do: Update the OWASP Dependency-Check Plugin to the latest patched release available from the Jenkins update center (all versions 5.6.4 and earlier are affected). Limit Item/Configure permission to trusted users and review recent job configuration changes for unexpected report content. Treat viewing of Dependency-Check reports in the Jenkins UI with caution until the plugin is patched.

The Jenkins Coverage Plugin fails to validate the coverage results ID supplied when a job configuration is submitted through the REST API, allowing an attacker with Item/Configure permission to store a URL using the javascript: scheme as the identifier. When other users subsequently view pages where that stored identifier is rendered, the embedded script executes in their browser session. Successful exploitation gives the attacker arbitrary script execution as the victim user, which can be used to steal sessions or credentials, modify Jenkins configurations, or perform actions with the victim's privileges. All Jenkins instances running Coverage Plugin 3.3358.v9487dde48783 or earlier are affected. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is currently known.

Do: Upgrade the Coverage Plugin to a fixed release newer than 3.3358.v9487dde48783 as soon as it is available. Until then, restrict Item/Configure permission to trusted users only and audit existing job configurations (via the REST API or UI) for javascript: URLs in the coverage results ID field, removing any that are found. Treat unexpected coverage ID changes as suspicious, since this permission is normally limited to authorized project configurators.

The Jenkins Warnings Plugin fails to validate the analysis results ID when a job configuration is submitted, including through the REST API. An attacker holding Item/Configure permission on a job can set the identifier to a URL using the javascript: scheme, which is then stored and rendered to other users, executing as a stored cross-site scripting (XSS) attack. Successful exploitation lets the attacker run arbitrary JavaScript in the browsers of other Jenkins users, enabling actions taken as the victim, session hijacking, and potential exposure of credentials or data readable in the victim's session (CVSS 8.0 high). Any Jenkins controller running Warnings Plugin 13.10258.va_17d49a_78c3b_ or earlier is affected, with the highest risk where Configure permissions are broadly granted or the REST API is used for job management. No public proof-of-concept or exploitation in the wild is currently known, and the flaw is not listed in CISA's KEV catalog.

Do: Upgrade the Jenkins Warnings Plugin to the newest release published after this advisory (versions 13.10258.va_17d49a_78c3b_ and earlier are vulnerable). In the meantime, limit Item/Configure permission to trusted users and restrict REST API access to job configuration. Audit existing job configurations for analysis results IDs set to javascript: or other unexpected URL schemes and remove them.

Jenkins GitLab Plugin 1.2149.vcfc32c82b_f7f and earlier caches the GitLab API client built for alternative GitLab API token credentials under a cache key derived from the credentials ID alone, omitting the folder in which the credentials are resolved, allowing attackers with Item/Configure permission to access GitLab API token credentials they are not entitled to use.

Jenkins Gradle Plugin 2.19.1252.v15196b_5a_6e10 and earlier requests build scan data from the build scan link detected in the build log, even when a Develocity server URL is configured in the global configuration, allowing attackers able to control the build log to capture the Develocity access key configured in the global configuration by having Jenkins connect to an attacker-specified URL.

Jenkins Pipeline: Groovy Libraries Plugin 805.va_fc79344957d and earlier does not restrict the library path provided to the library Pipeline step to a relative path inside the SCM checkout, and follows symbolic links to locations outside of the SCM checkout when retrieving the library, resulting in a path traversal vulnerability, allowing attackers able to configure Pipelines to read files in a resources directory and to delete files in a test directory on the Jenkins controller file system.

Jenkins Pipeline: Multibranch Plugin 841.vec5b_9e1806ec and earlier does not set the appropriate context for credentials lookup in the resolveScm Pipeline step, allowing attackers with Item/Configure permission to access and capture credentials they are not entitled to.

The Jenkins Script Security Plugin fails to apply sandbox checks to calls targeting methods that are added dynamically to a class at runtime, creating a protection-mechanism gap in its Groovy sandbox. An attacker who already has permission to define and run sandboxed scripts, such as Pipelines, can invoke such dynamically added methods to slip past the sandbox approval mechanism. Successful abuse yields execution of arbitrary code outside the sandbox on the Jenkins controller, with high impact to confidentiality, integrity, and availability. Any Jenkins instance running Script Security Plugin version 1415.v9a_f9b_3a_c253d or earlier is affected, though exploitation requires the attacker to hold script-authoring privileges, which is reflected in the high attack-complexity and low-privilege CVSS vector. No public proof of concept and no exploitation in the wild are currently known.

Do: Update the Script Security Plugin to the latest release published in the Jenkins security advisory (any version newer than 1415.v9a_f9b_3a_c253d). Until patched, limit which users or groups can create or run sandboxed scripts and Pipelines, and review recently granted script permissions. Administrators should also audit Pipeline job definitions and run logs for unexpected script activity, keeping in mind the network-reachable but privileged nature of this flaw.

The Jenkins Script Security Plugin, version 1415.v9a_f9b_3a_c253d and earlier, downloads a JAR file specified by URL twice when validating classpath entries: it confirms the sandbox approval against the first download but loads the classpath entries from the second. An attacker with permission to define classpath entries (for example, a user able to configure sandboxed scripts) can exploit this time-of-check/time-of-use gap by serving benign content for the approval fetch and malicious code for the load. Successful exploitation allows arbitrary code execution in the context of the Jenkins controller JVM, which typically means full compromise of the controller, its builds, and its stored credentials. Any Jenkins controller running an affected version of the plugin is exposed, though the attack requires low-privileged authenticated access and a high-complexity race between the two downloads. No public proof-of-concept or confirmed in-the-wild exploitation is currently known, and the issue is not listed in CISA KEV.

Do: Upgrade the Script Security Plugin to the latest release in the Jenkins update center (any version newer than 1415.v9a_f9b_3a_c253d). In the interim, restrict which users may define classpath entries or run sandboxed scripts (e.g., limit Job/Configure permissions and review script-approval settings), and audit existing classpath entries for URLs pointing to attacker-controllable hosts.

The Jenkins Script Security Plugin up to and including 1415.v9a_f9b_3a_c253d automatically approves pending classpath entries in an item's configuration whenever a user with Overall/Administer permission copies that item, or saves its configuration through the REST API or CLI. An attacker who holds Item/Configure permission on a job (for example, a non-admin user able to edit sandboxed Pipelines) can plant a malicious classpath entry and wait for any administrator to copy the item or update its config remotely, at which point the entry is silently trusted. This yields arbitrary code execution inside the Jenkins controller JVM, giving the attacker full control over the controller, its credentials, and all jobs. Any Jenkins controller running an affected version of the plugin where non-administrators can define classpath entries is exposed. No public proof-of-concept is known, the flaw is not in the CISA KEV catalog, and no exploitation has been reported.

Do: Upgrade the Script Security Plugin to a release newer than 1415.v9a_f9b_3a_c253d as published in the Jenkins security advisory. Until patched, restrict Item/Configure permission to trusted users, review pending classpath entries in the in-process script approval and classpath approval screens under Manage Jenkins, and refrain from copying items or editing job configurations via REST API or CLI with admin accounts. Audit job configurations for classpath entries submitted by untrusted users.

Jenkins Script Security Plugin 1415.v9a_f9b_3a_c253d and earlier does not reject @Builder annotations whose builderStrategy member names an arbitrary class, allowing attackers with permission to define and run sandboxed scripts, including Pipelines, to execute code outside the sandbox if a suitable class is present on the classpath of the component that evaluates the script.

The Jenkins Script Security Plugin, up to and including version 1415.v9a_f9b_3a_c253d, fails to reject the @GroovyASTTransformationClass annotation in sandboxed Groovy code, which is CWE-94 code injection by design of the sandbox filter. An attacker who already has permission to define and run sandboxed scripts — typically any user able to create or modify Pipeline jobs — can supply an arbitrary Groovy AST (Abstract Syntax Tree) transformation that the compiler executes at compile time, outside the sandbox's method-level interception. This bypasses the sandbox entirely and yields arbitrary code execution in the Jenkins controller JVM, giving the attacker control of the CI/CD server, its stored credentials, secrets, and connected build agents. The flaw is consistent with its CVSS 3.1 score of 8.8 (network vector, low complexity, low authenticated privileges required, no user interaction), and it affects most Pipeline-based Jenkins deployments that permit non-administrator users to write Pipelines. As of this analysis there is no public proof-of-concept, the issue is not in CISA's Known Exploited Vulnerabilities catalog, and no in-the-wild exploitation is known.

Do: Update the Script Security Plugin via the Jenkins update center to the first release after 1415.v9a_f9b_3a_c253d. In the interim, restrict which users have permission to define and run Pipelines or other sandboxed scripts, and audit existing users with those rights. Treat pending script approvals with caution, since AST transformations execute at compile time — during compilation and approval — before any patched sandboxing of script content applies.

The Jenkins Script Security Plugin, which restricts what Groovy code can do when users run sandboxed scripts, mishandles type casts on collections: it checks the operations Groovy performs with the elements read from a collection that a script casts to another type, but actually applies the cast to the collection itself. An attacker who already has permission to define and run sandboxed scripts, including Pipelines (a low-privilege, authenticated position per the CVSS vector), can craft a script that exploits this mismatch to perform operations the sandbox never approved. The result is a complete sandbox bypass and execution of arbitrary code in the context of the Jenkins controller JVM, giving the attacker control over the Jenkins instance, its stored credentials, jobs, and build agents. Any Jenkins controller running Script Security Plugin 1415.v9a_f9b_3a_c253d or earlier that grants sandboxed-script permissions to users is affected. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known at this time.

Do: Update the Script Security Plugin via the Jenkins update center to the newest release published after 1415.v9a_f9b_3a_c253d (see the Jenkins security advisory for the fixed version). Until patched, restrict which users or roles can define and run sandboxed scripts and Pipelines, and review controller logs for suspicious sandboxed-script activity. Administrators should re-check that the plugin is updated on every controller, since it is commonly pulled in automatically as a Pipeline dependency.

The Jenkins Script Security Plugin (1415.v9a_f9b_3a_c253d and earlier) fails to intercept Groovy operations performed on a null receiver — method calls, property and attribute accesses, and array accesses — leaving a gap in its sandbox protection mechanism (CWE-693). An attacker who already has permission to define and run sandboxed scripts, such as Pipeline jobs, can craft a script in which a null-receiver operation invokes privileged code that the sandbox never checks. Successful exploitation yields arbitrary code execution within the Jenkins controller JVM, giving the attacker full access to the controller, its stored credentials, and all jobs (CVSS 8.8 with high confidentiality, integrity, and availability impact). Any Jenkins controller running an affected plugin version where non-administrative users can author Pipelines or other sandboxed scripts is affected. No public proof-of-concept is known, the issue is not in CISA KEV, and there are no reports of exploitation in the wild.

Do: Update the Script Security Plugin to a release newer than 1415.v9a_f9b_3a_c253d as soon as a fixed version is published. Until then, restrict the permissions that allow users to create or edit Pipelines and other sandboxed scripts (e.g., Job/Configure and script-approval grants) to trusted users only, and review the sandbox approval list for overly broad approvals. Controllers that let anonymous or untrusted users define Pipelines carry the highest risk and should be prioritized, since exploitation requires authenticated script-authoring privileges.

The Jenkins Script Security Plugin fails to check method invocations made through the dynamic proxy that is created when a sandboxed script coerces a value to an interface, when the underlying value inherits a method whose name matches the interface method. An attacker who already has permission to define and run sandboxed scripts — most commonly users able to create or configure Pipelines on a shared Jenkins controller — can craft a script that abuses this coercion path to escape the Groovy sandbox. Successful exploitation yields arbitrary code execution inside the Jenkins controller JVM, which typically means full control of the controller, its credentials/secrets, and all connected build agents. Any Jenkins instance running Script Security Plugin 1415.v9a_f9b_3a_c253d or earlier is affected, and because the plugin is a core dependency of Pipeline, that includes most modern Jenkins deployments. No public proof-of-concept, listing in CISA KEV, or confirmed in-the-wild exploitation is known at this time.

Do: Update the Script Security Plugin to the first release published after this advisory (any version later than 1415.v9a_f9b_3a_c253d), which all controllers using Pipelines should receive promptly. In the meantime, restrict who can define and run sandboxed scripts — review users/groups with Item/Configure or Pipeline job-creation rights and Overall/RunScripts permission on shared controllers — and audit existing sandboxed jobs for scripts that coerce values to interfaces. Since exploitation requires script-running privileges, single-user or tightly restricted Jenkins instances face substantially lower practical risk than multi-tenant controllers.

CVE-2026-91843 is a stack-based buffer overflow (CWE-121) in the unauthenticated login process of a Check Point product, as Check Point Software ([email protected]) is the assigning CNA and its CVE scope covers Check Point products. An attacker can trigger the flaw remotely by sending crafted input to the login interface before authenticating, with no user interaction or credentials required. Successful exploitation allows arbitrary code execution with root privileges, the highest level of control on the affected system. The vulnerability is rated 9.8 Critical (AV:N/AC:L/PR:N/UI:N, all impacts high), reflecting trivial network exploitability. No public proof-of-concept or confirmed in-the-wild exploitation is known at this time, and the source data does not name the specific product line or affected version ranges.

Do: Monitor Check Point's official advisory channels for the affected product/version list and patch release, and upgrade as soon as fixed versions are published. In the interim, restrict the login/management interface of Check Point appliances to trusted management networks and remove any direct internet exposure, and review perimeter logs for anomalous pre-authentication traffic against that interface.

Adenion Blog2Social plugin for WordPress before 9.1.0 exposes the email addresses of all registered WordPress users to low-privileged accounts. The b2s_search_user AJAX handler in includes/Ajax/Get.php invokes B2S_Tools::searchUser() in includes/Tools.php, which returns the email address of every matching user without restricting access to callers holding the list_users capability, allowing any user with the edit_posts capability to retrieve user email addresses including those of administrators.

Adenion Blog2Social plugin for WordPress before 9.1.0 allows low-privileged users to enumerate WordPress user accounts. The b2s_get_select_mandant_user AJAX handler in includes/Ajax/Get.php resolves arbitrary user IDs supplied in the owner parameter to display names without verifying that the caller is authorized to read user account data, allowing any user with the edit_posts capability to map WordPress user IDs to display names and confirm account existence for arbitrary IDs.

MikroTik RouterOS versions before 7.24 ship a userspace SMB server whose SMB1 SessionSetupAndX handler fails to validate the uniPwdLen field: a crafted value triggers an integer underflow (CWE-191) and the resulting length is used to copy data into a smaller heap buffer, corrupting adjacent heap memory (CWE-122). Any unauthenticated remote attacker who can reach the SMB service can trigger the flaw with a single malformed SMB1 request, with no credentials or user interaction required. The scored impact is high availability loss — the heap corruption can crash the SMB daemon/service — while confidentiality and integrity impacts were not demonstrated; heap corruption can in principle enable deeper exploitation, but no such exploit is documented. All RouterOS deployments older than 7.24 carry the flaw, but only devices with the SMB server enabled and network-reachable are exploitable in practice (the CVSS 'high attack requirements' metric reflects that the service is not enabled in default configurations). The vulnerability is not in CISA's KEV catalog, no public proof-of-concept is known, and no exploitation has been reported to date.

Do: Upgrade all RouterOS devices to version 7.24 or later. Where immediate upgrade is not possible, disable the SMB server (/ip smb set enabled=no) and ensure TCP 445 is filtered on WAN-facing interfaces, since exploitation requires network reachability to the SMB service. Audit deployments for enabled SMB and internet-exposed port 445, and watch for SMB daemon crashes as a potential indicator of targeting.

In Sooma 2GEN brain stimulator, an attacker within Bluetooth range can make unauthenticated changes to brain stimulation parameters.

ISC BIND 9 recursive resolvers spend disproportionate CPU time constructing a response when queried for the root of a tree of SVCB/HTTPS AliasMode records that they have already cached, creating an algorithmic-complexity denial-of-service condition (CWE-1050). An unauthenticated remote attacker can trigger it simply by sending such a query to a resolver holding a cached AliasMode tree, requiring no privileges or user interaction (CVSS AV:N/AC:L/PR:N/UI:N). The attacker's gain is denial of service: the named process wastes excessive CPU on crafted queries, degrading or halting DNS resolution for the clients that depend on that resolver. Only caching/recursive BIND 9 resolvers within the affected ranges of the 9.18, 9.20, 9.21 and supported -S1 subscription branches are affected; authoritative-only servers do not maintain this cache. No public proof-of-concept is known, the issue is not on CISA's KEV list, and no in-the-wild exploitation has been reported.

Do: Upgrade each deployed branch to the patched release outside the listed ranges (i.e., later than 9.18.50 / 9.20.27 / 9.21.25 or the corresponding -S1 builds) as published in ISC's advisory. Until patched, verify your version with 'named -v', ensure the resolver is not open to the internet by restricting recursion to trusted clients, monitor named CPU utilization for anomalies, and flush the cache if a suspicious SVCB/HTTPS AliasMode tree is suspected.

A BIND recursive resolver that processes an SVCB or HTTPS AliasMode record referencing 14 or more SVCB/HTTPS ServiceMode records fails to deallocate internal resources, leaking memory with each lookup (CWE-401). A remote, unauthenticated attacker can trigger this repeatedly, for example by pointing their own domains at crafted record chains that the resolver is asked to look up, until resource exhaustion prevents the resolver from performing any new recursive lookups. The impact is a high-severity denial of service against recursive DNS service; there is no confidentiality or integrity impact. All operators running affected BIND 9.18, 9.20, or 9.21 (including the -S1 Stable Preview editions) as resolvers are exposed, with internet-facing recursive resolvers at greatest risk. As of now there is no known exploitation in the wild, no public proof-of-concept, and the flaw is not listed in CISA's KEV catalog.

Do: Upgrade resolvers to the patched BIND release on your branch per ISC's CVE-2026-81563 advisory — i.e., any release newer than 9.18.50, 9.20.27, 9.21.25, 9.18.50-S1, or 9.20.27-S1 as applicable. Until patched, restrict recursion to trusted clients (allow-recursion ACLs) so internet hosts cannot drive lookups, and monitor resolver memory, restarting services that show abnormal growth. Treat unexplained loss of recursive resolution ability as a possible sign of exploitation.

ISC BIND 9's named daemon incorrectly treats an NS or DNAME node placed above a zone's origin as a zone cut, so an attacker who can insert a malformed zone into an authoritative server (for example, via zone transfer or by loading zones on a shared DNS service) can make queries within that configured zone lose authoritative status and return an out-of-zone delegation. On servers that also provide recursion, BIND then follows this locally sourced, attacker-influenced cut and caches attacker-supplied data, poisoning answers for names outside the configured zone; the condition persists for as long as the malformed zone remains in the zone database. Any deployment running an affected BIND 9 version that combines authoritative service for attacker-influenceable zones with recursion, or that accepts zone transfers from less-trusted sources, is exposed. ISC assigned it CVSS 5.8 (medium) with high attack complexity and high privileges required, reflecting these preconditions. There is no evidence of exploitation in the wild, no known public proof-of-concept, and the flaw is not listed in CISA KEV.

Do: Upgrade each affected BIND 9 branch to the first ISC-patched release after the last affected version listed for that branch (including the -S1 subscription branches). Meanwhile, restrict AXFR/IXFR zone transfers to trusted peers with TSIG-signed allow-transfer ACLs, run authoritative and recursive service on separate named instances or disable recursion on authoritative-only servers, and audit zone files and transferred zones for NS or DNAME records at or above the zone origin, removing any malformed zone and flushing the cache if found.

ISC BIND 9 contains a NULL pointer dereference (CWE-476) that causes the `named` daemon to abort when it receives a DNS-over-HTTPS request carrying a cryptographically invalid SIG(0) record followed by a premature close of the transport connection. An unauthenticated remote attacker can trigger the crash repeatedly, achieving a denial of service with no confidentiality or integrity impact (CVSS availability-only). Only deployments running affected 9.20.x, 9.21.x, or 9.20.x-S1 versions with DoH listeners configured are exposed; servers without DoH endpoints enabled are not vulnerable. No public proof-of-concept exists, the flaw is not in the CISA KEV catalog, and no exploitation in the wild has been reported.

Do: Upgrade to the patched releases published by ISC for the 9.20, 9.21, and 9.20-S1 branches (see the corresponding ISC advisory for exact fixed version numbers). As an interim mitigation, disable or remove DNS-over-HTTPS (http) listeners in named.conf, or restrict DoH endpoints at the firewall/ACL level to trusted clients. Check whether your named.conf defines http endpoints and whether port 443 DoH service is internet-facing; if not, your exposure is limited.

The Advantech EKI-1242EIMS at firmware version V1.06.01 does not cryptographically verify firmware images during the update process, an insufficient verification of data authenticity flaw (CWE-345) identified by Nozomi Networks Labs. An attacker who is already authenticated as an administrator can upload a modified firmware image through the device's web management interface, and the device installs it without any signature or certificate check. Successful exploitation yields full, persistent compromise of the platform, since the attacker-controlled firmware remains resident on the device. Organizations running the EKI-1242EIMS, typically in industrial and OT deployments, are affected; the requirement for administrator-level credentials means risk is highest where such credentials could be stolen, reused, or abused by insiders. No public proof-of-concept is known, the vulnerability is not in CISA's KEV catalog, and no in-the-wild exploitation has been reported.

Do: Upgrade the EKI-1242EIMS to a fixed firmware release from Advantech as soon as one is published (V1.06.01 is the version confirmed affected; check the vendor advisory for the patched build). Until then, restrict web management access to trusted administrative hosts, segment the device from untrusted networks, and only flash firmware obtained directly from official Advantech sources. Audit administrator credentials and review devices for signs of unauthorized firmware changes.

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.

MikroTik RouterOS before 7.24 contains an out-of-bounds read vulnerability in the userspace SMB daemon that allows unauthenticated attackers to read beyond the end of the request buffer by supplying a crafted uniPwdLen field value in a minimal SMB1 SessionSetupAndX frame. The out-of-bounds read occurs in the SessionSetupAndX handler before any credential validation, potentially exposing sensitive memory contents.

This is a DNSSEC validation flaw (CWE-345) in BIND 9's `named` resolver, which may accept an inapplicable NSEC record as valid proof that no wildcard record exists for a zone name. An attacker positioned at the same or an upstream level of the victim's zone name — for example, an operator of a sibling or parent zone able to present the malformed NSEC proof — can trigger the flaw in a validating resolver. The result is that the victim's wildcard record is treated as nonexistent, so the attacker can spoof or suppress answers in a way that still passes DNSSEC validation, yielding a high integrity impact (no confidentiality or availability impact per the CVSS vector). Only operators running affected BIND 9 versions as validating resolvers, particularly zones that rely on wildcard records, are affected. The issue was disclosed by ISC as one of fourteen BIND 9 vulnerabilities; it is not in CISA's KEV catalog and no public proof-of-concept or known exploitation exists.

Do: Upgrade all validating `named` resolvers to the patched BIND 9 releases published by ISC for each affected branch (i.e., releases newer than 9.18.50, 9.20.27, 9.21.25 and the corresponding -S builds), per ISC's advisory for CVE-2026-19941. Administrators of DNSSEC-signed zones that depend on wildcard records should investigate client reports of unexpected NXDOMAIN/nodata answers. Restricting recursion to trusted clients is a useful defense-in-depth measure, but patching is the only complete fix.

CVE-2026-19667 is a numeric type conversion error (CWE-197) in ISC BIND's `named` resolver: when an authoritative server returns a negative answer (e.g., NXDOMAIN/NODATA) that is exactly 65536 bytes long, `named` mis-handles the size and stores a 0-byte negative cache entry. When that cache entry is subsequently read to answer a client query, the `named` process aborts, taking down the resolver's DNS service. An attacker who controls an authoritative server for any domain the resolver will look up (e.g., a domain they own, with lookups induced via links or other references) can crash an unpatched recursive resolver remotely without credentials. Organizations and providers running affected BIND 9 versions as caching/recursive resolvers are affected; purely authoritative servers are not the relevant exposure. As of publication there is no known public proof-of-concept, the flaw is not listed in CISA KEV, and no exploitation has been reported.

Do: Upgrade caching/recursive BIND resolvers to a patched release beyond the affected ranges listed in ISC's advisory (i.e., newer than 9.18.50, 9.20.27, 9.21.25 and the corresponding -S1 preview builds), and verify running versions with `named -v`. Restrict recursion to trusted client networks to reduce who can be leveraged to trigger lookups, and monitor resolvers for unexpected `named` aborts/restarts. Authoritative-only servers that do not perform recursion and negative caching are not meaningfully exposed.

CVE-2026-19662 is a use-after-free flaw (CWE-416) in ISC BIND 9's named resolver that can cause the daemon to abort, resulting in a denial of service. An attacker must operate an authoritative server hosting a DNSSEC-signed zone and induce the victim resolver to send multiple queries to it; the crash only occurs if the attacker's crafted answers arrive in a particular sequence, order, and timing, making the attack reliable but non-trivial (CVSS attack complexity is High). A successful attack yields no data theft or tampering — only a crash of the resolver process (availability impact rated High). Any organization running an affected BIND 9 version as a recursive resolver is potentially exposed, since the resolver can be steered to the attacker's authoritative server via queries from its clients. There is no known public proof-of-concept, the flaw is not in CISA's KEV catalog, and no in-the-wild exploitation is reported; it was disclosed by ISC as part of a batch of fourteen BIND 9 vulnerabilities.

Do: Upgrade all recursive BIND 9 resolvers past the affected ranges — i.e., to the first maintenance releases of the 9.18, 9.20, and Supported Preview (S1) branches issued after 9.18.50/9.20.27 and the matching -S1 builds, per ISC's advisory covering these fourteen CVEs. Until patched, restrict recursion to trusted client networks only, and monitor named logs for unexplained resolver aborts/restarts, which would indicate attempted triggering. Authoritative-only servers that do not perform recursion are not meaningfully exposed to this attack path.

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.