WP Rentals theme through 3.14.2 contains a missing authorization flaw (CWE-862) that lets unauthenticated remote attackers trigger unauthorized state-changing actions through incorrectly configured access controls. The CVSS:3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N indicates no authentication, no user interaction, and only low integrity impact, with no confidentiality or availability impact, making this a moderate-priority issue rather than a top-tier emergency. No public exploit identified at time of analysis, and default installations running affected versions are exposed.
Unauthenticated information disclosure in the WP Chill Modula Image Gallery WordPress plugin (modula-best-grid-gallery) through version 3.0.11 lets remote attackers retrieve embedded sensitive data from a site without logging in or triggering any user interaction. The missing authorization check (CWE-862) affects an exposed plugin route, but impact is limited to low-confidentiality read access - there is no ability to modify content or execute code. No public exploit code has been identified at time of analysis and there is no indication of active exploitation, so this is a moderate, not high, priority; any network-reachable WordPress site running the vulnerable plugin build is exposed, while sites on a patched release or without the plugin active are unaffected.
Multiple memory-safety defects in X.Org X server prior to xorg-server-21.1.25 and Xwayland prior to xwayland-24.1.14 let an authenticated X client corrupt server heap and stack memory through crafted XKB, Present, XInput2, GLX and XFixes protocol requests, causing crashes or potentially arbitrary code execution inside the X server process. The flaws include a double free in XKB SetGeometry TextDoodad handling, use-after-frees in the Present cross-window notify path and in XInput passive grabs after XIRemoveMaster, heap overflows in GLX RenderLarge and XkbResizeKeyType, an XFixes pointer-barrier event buffer overflow, and an incomplete-fix out-of-bounds write in the XKB ChangeKeycodeRange path. Exploitation requires a connection already authorized to the X server (typically a local user session, an X11-forwarded session, or a multi-seat/shared-display host); no public exploit code and no confirmed in-the-wild exploitation have been identified at time of analysis, and the assessed vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Pure-Wayland deployments that do not run Xwayland are not exposed.
Path traversal in Cisco Jabber for Android (com.cisco.im) before 15.3.1.311364 lets a locally installed malicious app with no requested permissions write attacker-controlled files into Jabber's private application data directories. The attacker sends a crafted shared content:// URI to Jabber's exported crosslaunch.share activity whose unsanitized ContentProvider display name contains '../' sequences; because that display name is used directly in file-path construction, files can be planted in databases/, shared_prefs/, no_backup/, and files/ with no user interaction. Impact is integrity-only and confined to Jabber's own sandbox (CVSS v4.0 5.1, AV:L/PR:N/UI:N/VC:N/VI:L/VA:N); no public exploit code and no confirmed active exploitation were identified at time of analysis, and the attack surface is local - the adversary must already have code executing on the device.
Path traversal in pulp-rpm's distribution tree publishing allows an authenticated user with sync or upload privileges to write files outside the intended task work area on the Pulp server. Crafted addon or variant ids in a .treeinfo file are used as directory names without sanitization, enabling the creation of new directories and writing of repository metadata and packages as the Pulp worker user. This is an integrity-only issue with no data disclosure or service disruption; no public exploit has been identified, and the practical risk is lower than the base CVSS 5.0 suggests due to the required privileges and the create-only constraint.
Sensitive information disclosure in the @backstage/plugin-kubernetes-backend package before version 0.21.9 allows an authenticated Backstage user who holds the standard Kubernetes resource read permission to retrieve Kubernetes Secret values that the plugin is designed to mask. The flaw is specifically reachable through the custom resources query path, where both the `data` and `stringData` fields of Secrets were returned unmasked, potentially exposing credentials and other confidential material held in connected clusters. Exposure is bounded by the Backstage service account's RBAC scope and by the targeted catalog entity's namespace and label selector, so deployments whose cluster credentials cannot read those resources are unaffected; there is no public exploit code identified at time of analysis and the issue carries a moderate CVSS of 5.0.
OS command injection in the web-based management interface of Cisco License On-Prem (formerly Cisco Smart Software Manager On-Prem) allows an authenticated remote attacker holding system administrator credentials to submit a crafted configuration update that is executed as root on the underlying operating system. Scored CVSS 4.9 (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H), the flaw is heavily constrained by its PR:H authentication prerequisite: because the attacker must already be a full administrator, the marginal capability gained is limited to shutting down or disrupting the host (availability impact only), which the assessed vector reflects with C:N/I:N/A:H. No public exploit code was identified at time of analysis and the issue is not in CISA KEV; no EPSS score was supplied in the source data.
Authenticated SQL injection in the web-based management interface of Cisco License On-Prem (formerly Cisco Smart Software Manager On-Prem) lets an attacker who already holds valid administrative credentials send a crafted request that reads internal database contents normally hidden from administrative users, impacting confidentiality only. The flaw is rated CVSS 3.1 4.9 (Medium) with the vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N, confirming it is remotely reachable but gated behind high privileges, with no integrity or availability impact and no user interaction required. There is no KEV listing and no public exploit identified at time of analysis, so the realistic risk is concentrated among insiders or anyone who has obtained administrator credentials for the license management portal rather than anonymous internet attackers.
Admission control bypass in Apache YuniKorn 1.9.0 and earlier allows an authenticated user who can already submit pod specs to the Kubernetes cluster to set the label 'app=yunikorn' on a pod, which causes the admission controller to skip its content checks on the 'user info' annotation. The attacker can therefore inject an arbitrary user identity, gaining access to queues they would not normally be permitted to use and distorting the user-based quota accounting that YuniKorn relies on for fair-share enforcement. Impact is confined to queue access and quota tracking (no data disclosure or denial of service), no public exploit code was identified at time of analysis, and the issue is fixed in 1.10.0 (tracked as YUNIKORN-3472).
Cross-site scripting in Veeam Backup Enterprise Manager lets an attacker run arbitrary script in the browser of a portal user who opens a crafted link, potentially exposing session data or allowing actions in the victim's authenticated context. Exploitation is not autonomous: the attacker must already be able to reach the portal with a valid low-privileged account (CVSS PR:L) and must then persuade a logged-in portal user to open the crafted link (UI:A), which is why this is rated a genuinely moderate, not high-priority, issue at 4.8. No public exploit code has been observed and the vulnerability is not in CISA KEV; no EPSS score was supplied with the source data, so likelihood should be treated as bounded by the social-engineering and authentication prerequisites rather than as an opportunistic mass-exploitation risk.
wger before 2.6 fails to revoke bearer-style API credentials on logout or password change, allowing an attacker who already holds a stolen DRF authtoken or JWT refresh token to continue accessing protected /api/v2/* endpoints. The assessed CVSS is 4.8 with vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, reflecting a moderate defense-in-depth authentication weakness rather than a high-urgency flaw. Publicly available exploit code exists in the form of proof-of-concept replay steps, but exploitation requires prior token theft and the vulnerability provides no means to obtain the token; active exploitation is not confirmed.
UNIX symlink-following in ImageMagick's delegate cleanup path allows a local, already-privileged workflow to overwrite a target file with random data. Affected are ImageMagick versions prior to 7.1.2-32 and the ImageMagick6 branch prior to 6.9.13-57; the flaw (CWE-61) causes the shred/cleanup routine to ignore the MAGICK_SHRED_PASSES setting, so it follows attacker-planted symbolic links instead of honoring the configured shred behavior. The attack surface is narrow - CVSS 3.1 scores this 4.0 (AV:L/AC:H/PR:H/UI:R) with integrity-only impact - and no public exploit has been identified at time of analysis; there is no CISA KEV designation.
Python sandbox escape in Cisco NX-OS allows an authenticated, local attacker with low privileges to break out of the on-box Python interpreter sandbox and run arbitrary commands on the underlying operating system with that user's privileges. The issue arises from insufficient validation of user-supplied input in specific interpreter functions, affecting NX-OS software per the vendor CPE, and requires local access plus a valid low-privilege account rather than remote or unauthenticated access. No public exploit identified at time of analysis; CVSS 4.4 reflects limited confidentiality and integrity impact, and Cisco has published advisory cisco-sa-nxos-mppe-dhKZAFgb for affected platforms and versions.
Authenticated users of IBM Langflow OSS 1.0.0 through 1.12.2 can exhaust server resources by supplying a crafted ZIP archive to a code path that performs extraction, degrading or halting availability of the affected instance (CVSS 3.1 base 4.3, CWE-400). The flaw is reachable over the network by a low-privilege authenticated attacker (AV:N/PR:L/UI:N) and is limited to availability impact (C:N/I:N/A:L), with no data exposure, integrity loss, or code execution demonstrated. This is a low-to-moderate priority issue, not an urgent one: it is not confirmed as actively exploited (no CISA KEV listing) and no public exploit code has been identified at time of analysis, though the mandatory credential requirement means exposure is confined to deployments with reachable ZIP-extraction functionality.
Splunk Enterprise deployments below 10.4.3, 10.2.7, 10.0.10, and 9.4.15 leak other users' search activity to any authenticated user who does not hold the admin or power role, exposing search query text, job identifiers, dispatch parameters, result counts, and execution metadata through the REST API endpoint that lists search jobs. The flaw is an authorization enforcement gap: the listing API does not fully apply per-user checks before including job information belonging to other accounts, so an attacker with any low-privileged credentials can read searches they should never see. Scored CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), it is a low-severity confidentiality issue with no public exploit identified at time of analysis; because a valid account with PR:L is required, the practical exposure is an insider or post-credential-compromise scenario rather than a remote-unauthenticated attack.
Permission-filtered search in Backstage deployments that use an Elasticsearch or OpenSearch backend can return documents that a DENY policy should have withheld, because an empty list of permitted document types causes the engine to issue an unfiltered query across all indices instead of returning zero results. Only authenticated Backstage users (CVSS PR:L) are positioned to trigger this, and only when permission.enabled is set to true, the search backend is Elasticsearch/OpenSearch rather than the default in-memory engine, and the user is actually governed by a DENY policy for one or more search document types; the impact is limited to confidentiality (C:L) with no integrity or availability effect. The vendor has released fixes in @backstage/plugin-search-backend 2.1.6 and @backstage/plugin-search-backend-module-elasticsearch 1.8.7 (Backstage release v1.54.1), and there is no public exploit identified at time of analysis. Consistent with our independent assessment, this is a genuine but low-urgency information-disclosure issue rather than a high-priority emergency.
Low-privileged Splunk Enterprise users can retrieve the original source code of the Discover Splunk Observability Cloud app because production JavaScript bundles shipped with the app retain embedded source maps. The issue affects Splunk Enterprise below 10.4.3, below 10.2.7, and below 10.0.10 (10.0.x, 10.2.x, and 10.4.x branches); the 9.4.x line is explicitly not affected. Exploitation requires an authenticated account that does not hold the 'admin' or 'power' roles plus access to Splunk Web and the presence of the affected app, and the resulting disclosure is confined to the app's own source code with no integrity or availability impact; no public exploit has been identified at time of analysis, and vendor fixes are available.
Improper authorization in Splunk Enterprise (CWE-863) allows an authenticated user who does not hold the 'admin' or 'power' role to create or edit scripted lookup definitions through the raw transforms configuration write paths, which save those settings without applying the external lookup capability check that the standard lookup management UI enforces. Deployments running versions below 10.4.2, 10.2.6, 10.0.10, or 9.4.15 are affected, and exploitation requires a valid low-privilege account plus network access to the Splunk management/REST interface. The assessed CVSS 3.1 base score is 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), a moderate integrity-only authorization flaw; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Splunk Secure Gateway (an app bundled with Splunk Enterprise) fails to verify that a requesting user is authorized to ask for a payload signature, so any authenticated Splunk user who does not hold the 'admin' or 'power' roles can coerce the gateway into signing attacker-controlled content. Affected builds are Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, together with Splunk Secure Gateway versions below 3.10.11, 3.9.25, and 3.8.72, as catalogued under CPE cpe:2.3:a:splunk:splunk_secure_gateway and cpe:2.3:a:splunk:splunk_enterprise. The impact is integrity-only (CVSS 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N): no confidentiality or availability effect, authenticated access and network reachability to the gateway are required, and there is no public exploit identified at time of analysis. Exploitation is confirmed as not appearing in CISA KEV, so the practical risk is confined to deployments where platform-signed payloads are subsequently trusted by downstream consumers.
Authenticated Splunk Enterprise users whose role holds the run_collect capability can bypass their role's configured index-access restrictions and write events into internal indexes they are not permitted to modify, because Splunk does not normalize whitespace in an index name before enforcing per-role index access. The flaw affects Splunk Enterprise releases below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, and carries a CVSS 3.1 score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) - an integrity-only, low-severity impact with no disclosure of data and no service disruption; no public exploit identified at time of analysis.
Authenticated Splunk Enterprise users whose roles carry the run_collect capability can inject attacker-controlled content into system-level messages on the affected instance because the collect Search Processing Language (SPL) command fails to validate the index name before processing it. The flaw affects Splunk Enterprise 10.4 before 10.4.3, 10.2 before 10.2.7, 10.0 before 10.0.10, and 9.4 before 9.4.15, and is limited to a low integrity impact (CVSS 4.3, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with no confidentiality or availability loss and no user interaction required. Exploitation requires valid credentials plus a role granting run_collect - a non-default prerequisite that standard or restricted roles lack - and no public exploit has been identified at time of analysis; vendor patches are available, and this is a low-priority issue despite being network-reachable.
Authenticated log injection in Splunk Enterprise allows a user whose role carries the read_o11y_content capability to forge entries in the app log through the REST API, but only on deployments where the Splunk App for Splunk O11y Cloud is present and enabled. The root cause is CWE-117 - the app writes user-supplied SignalFlow content into the app log without neutralizing it - producing a low-impact integrity-only result (CVSS 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with no confidentiality or availability effect, and no public exploit identified at time of analysis. Only Splunk Enterprise releases below 10.4.3, 10.2.7 and 10.0.10 are affected; 9.4.x is explicitly not affected.
An authenticated user with the edit_spl2_module_permissions capability in Splunk Enterprise 10.0.x before 10.0.10, 10.2.x before 10.2.7, and 10.4.x before 10.4.3 can bypass an app-read authorization check via the REST management API to retrieve SPL2 module permission grants for apps they are not permitted to view. This low-severity authorization flaw (CVSS 4.3, CWE-639) results only in limited disclosure of permission-grant metadata, with no write or availability impact, and no public exploit has been identified at time of analysis. Splunk Enterprise 9.4.x is not affected.
Missing authorization in the Booktics WordPress plugin (versions up to and including 1.0.27) allows authenticated low-privilege users to access restricted data, resulting in limited confidentiality exposure. The flaw requires a valid account on the target site but no administrative rights and no user interaction, affecting only sites with the plugin installed and activated. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the CVSS score is 4.3 (moderate).
Missing authorization checks in the WPMU DEV Hustle WordPress plugin (wordpress-popup) through version 7.8.14.2 allow an authenticated user holding only a low-privileged account to read data exposed by an access-control-protected feature that should be restricted to higher-privileged roles. The exposure is read-only - confidentiality is the only impacted property (CVSS 3.1 score 4.3, vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) - and requires no user interaction and no administrative rights, so the practical barrier is simply having any valid account on the target site. There is no public exploit code identified at time of analysis and the issue is not flagged as actively exploited, so this should be handled as a routine patch item rather than an emergency; sites that permit open user registration face the greatest exposure.
Values written through the PostgreSQL JDBC Driver (pgjdbc) 42.7.4 and 42.7.5 over a GSS/Kerberos-encrypted connection can be silently stored by the server with bytes from the driver's previous GSS send buffer spliced into the front of them, so the persisted value holds earlier SQL text, other bind parameters, or earlier rows of the same batch instead of what the application supplied. Only connections where gssEncMode is set to prefer or require are affected - the default gssEncMode=allow and all non-GSS-encrypted connections are not - and the write must be at least as long as the driver's 16320-byte GSS buffer (with MIT Kerberos) and issued via setString, setBytes, a ByteStreamWriter, CopyIn.writeToCopy, or LargeObject.write. The CVSS vector (PR:L) indicates an authenticated database session is required, most qualifying writes fail outright with an ArrayIndexOutOfBoundsException rather than leaking, no public exploit is identified at time of analysis, and the upstream project rates this as a genuine but low-priority defect (CVSS 4.2) rather than a high-urgency threat.
Splunk Enterprise below 10.4.3, 10.2.7, 10.0.10, and 9.4.15 fails to reject native usernames that end with a trailing period, allowing an authenticated user who holds a role with the edit_user capability to create such an account. Because the trailing period is stripped or normalized when deriving the per-user directory path, two distinct native usernames can resolve to the same per-user configuration data, so user-management operations may act on the wrong account or fail outright. The practical exposure is bounded: exploitation requires a high-privilege administrative capability (edit_user) on native Splunk authentication, and the outcome is configuration-data collision and misdirected administrative actions rather than code execution or bulk data theft. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; vendor-released fixes are available. This is a low-priority, low-real-risk issue despite affecting a widely deployed enterprise product.
Local arbitrary file write in Veeam Agent for Microsoft Windows allows an authenticated low-privileged local user to escalate integrity impact when an administrator installs or runs the agent. The vulnerability requires a privileged install/run action during the attack window and a non-trivial precondition such as controlling a target filesystem path (e.g., junction/symlink), making exploitation gated and low-to-moderate priority. No public exploit was identified at time of analysis.
AsyncHttpClient (AHC), a Java library for asynchronous HTTP requests, contains an incomplete cookie Domain validation flaw in its ThreadSafeCookieStore: from 2.16.0 through 2.16.1 and from 3.0.11 through 3.0.13, the store fails to apply private-section and default public-suffix rules, A-label (IDN) normalization, locale-independent lowercasing, and proper host-only and numeric/IP host checks, so a cookie set by one origin can be stored and later replayed to a different origin. Applications that share a single client instance across distinct trust domains can therefore receive attacker-injected cookies and may be exposed to session fixation; the assessed impact is integrity-only (CVSS 3.1 4.0, AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N) with no data disclosure. Exploitation is constrained by a non-default deployment pattern (per-origin or per-trust-boundary clients are not affected) and by the attacker needing to control or inject a Set-Cookie response from one of the shared origins; no public exploit code was identified at time of analysis, and the vendor has released a fix in version 3.0.14.
Improper JWT/OAuth bearer-token validation in Apache Impala executors (versions 4.1.0 through 4.5.2) lets remote, unauthenticated attackers read resources exposed by an executor's internal webserver, because JWT signatures are never verified and any syntactically valid token is accepted. The exposure is conditional: it only applies where the executor webserver has been explicitly configured to accept JWT/OAuth bearer-token authentication, which is not the default, and the attacker must have network reachability to that webserver endpoint. EPSS is low (0.20%, ~9th percentile) and no public exploit code or confirmed active exploitation has been identified at time of analysis, but the flaw is trivially exploitable once the non-default configuration is in place; the assessed impact is high confidentiality with limited integrity loss, and the vendor fix is Impala 4.5.3 or disabling JWT/OAuth on executors.
HTTP Digest authentication in AsyncHttpClient (Java) prior to 3.0.12 and 2.16.1 derives the client nonce (cnonce) from ThreadLocalRandom rather than a cryptographically secure source, weakening the Digest exchange against chosen-plaintext and credential-precomputation attacks for an observer who can infer generator state. The issue is rated CVSS 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N), so per the assessed vector no authentication is required from a remote attacker, but exploitation is statistical and high-complexity rather than a direct exploit. Only applications that use AsyncHttpClient's Digest auth via Realm.Builder are affected; no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV is not indicated).
Improper verification of the WebSocket opening handshake in AsyncHttpClient (AHC) versions prior to 3.0.12 and 2.16.1 lets a malicious or man-in-the-middle WebSocket endpoint have frames decoded and delivered to the application's WebSocketListener even though the server's Sec-WebSocket-Accept value was missing or invalid and the 101 upgrade was never authenticated. Only Java applications that use the WebSocketUpgradeHandler on an affected AHC release and connect to an attacker-controlled or intercepted endpoint are exposed, and because the request future still fails and the channel is closed the window for delivering coalesced frames is narrow and the impact is limited to integrity of listener-delivered data. No public exploit code has been identified at time of analysis and the issue is not known to be actively exploited, consistent with its low CVSS 3.1 score of 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
Local denial of service in m17n-lib, the multilingual input-method library shipped in Red Hat Enterprise Linux 6 through 10, can crash an application that opens an input method: a partial failure during library initialization leaves an internal driver pointer uninitialized, and the subsequent dereference is performed without validation. The assessed risk is genuinely low (CVSS 3.1 base 2.9; AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L), because the trigger - system resource exhaustion or corruption of the input-method database - is rare and cannot be reliably forced, the vector is local rather than remote, and the impact is confined to an application crash with no confidentiality or integrity effect. No public exploit identified at time of analysis, and there is no indication of active exploitation (not in CISA KEV).
Obot versions 0.25.0 through 0.25.5 and 0.26.0 can persist stale group memberships after an administrator revokes a user's group in the upstream identity provider, leaving the user with revoked group-based access for roughly ten minutes. The flaw is a race condition (CWE-362) in the auth provider group-refresh path: when two refreshes for the same identity overlap and commit out of order, an older refresh overwrites the newer one and restores memberships that were just removed. It is a genuinely low-priority issue - the CVSS 4.0 score is 2.3 (assessed independently as CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N), exploitation requires an already-authenticated user (PR:L), the timing is not attacker-controllable (AC:H), impact is limited to retaining previously held access rather than gaining new privileges, and the condition self-heals within the group check period; no public exploit code has been identified at time of analysis and there is no CISA KEV entry.
An out-of-bounds read in Apache YuniKorn's non-default LDAP group resolver allows a malformed LDAP group-membership entry to panic the scheduler process in versions 1.8.0 through 1.9.x, making the scheduler unavailable until it is restarted. The crash occurs only when an installation has explicitly configured the LDAP group provider and the LDAP server returns a memberOf entry for a user referenced in a submitted pod that does not begin with the 'CN=' prefix; default installations that use the built-in group resolution are not affected, and successful triggering generally requires an authenticated, low-privileged user able to have a pod processed. This is a low-severity, availability-only defect - CVSS 4.0 base score 2.1 (low) and an independently assessed CVSS 3.1 vector of AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L - with no public exploit identified at time of analysis and no confirmed active exploitation; a vendor fix is available in 1.10.0.
Heap-based buffer overflow in XnView Classic 2.52.5 allows a crafted FLI file to corrupt heap memory when a victim opens it, requiring user interaction and no authentication; publicly available exploit code exists per the CVSS v4.0 E:P metric. This client-side parsing flaw has low confidentiality, integrity, and availability impact, making it a moderate-severity, low-priority issue, and upgrading to version 2.52.6 is recommended.
Admission-control bypass in Apache YuniKorn 1.9.0 and earlier allows an authenticated Kubernetes user who holds UPDATE/patch permission on workload objects (deployments, replicasets, statefulsets, daemonsets, jobs, cronjobs) to set an arbitrary user-info annotation and rewrite the workload's application ID, potentially gaining placement into a queue the user would not normally be entitled to and sidestepping user-based quota accounting. The CREATE path correctly enforces the label and user-annotation checks, so the flaw exists only on the UPDATE action, meaning an attacker must first create a workload and then modify it - reflected in the vendor CVSS 4.0 base of 2.0 (AV:N/AC:L/AT:P/PR:H/UI:P, integrity-only) and in the independent assessment (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N). Impact is confined to multi-tenant queue isolation and quota governance with no host, data, or code-execution exposure; no public exploit identified at time of analysis. The issue is tracked as YUNIKORN-3473 and fixed in YuniKorn 1.10.0 (also landed in the 1.11.0 fix version) via GitHub PR #1106.
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: preserve mremap address delta when skipping page tables move_hugetlb_page_tables() optimizes mremap() by advancing to the last entry in the page table when the source page table does not exist, either initially or after unsharing a PMD table. The common loop increment then steps to the first entry in the next page table. However, the code advances both the source and destination addresses to the last entries in their respective page tables, which is wrong. The destination address must be advanced only by the same amount as the source address. If the source and destination offsets within their page tables differ, the destination address can be advanced too far, causing follow-up issues. Fix this by advancing the destination address by the source advance distance. With a reproducer, we were able to trigger a kernel panic on x86-64. With this fix in place, we can no longer reproduce the issue.