A flaw was found in automation-controller. The notification template Jinja whitelist only inspects static Getattr AST nodes. An attacker with notification template admin privileges can bypass the whitelist using dynamic subscript expressions or conditional gating on runtime values that differ from the test-render stub. Exceptions raised during notification rendering write full Python tracebacks into the notification body, which is sent to the attacker-controlled webhook URL, leaking install paths, Python version, and source file line numbers.

A flaw was found in automation-controller. The LaunchConfigurationBaseSerializer used by Schedule and WorkflowJobTemplateNode does not implement ▎ validatescmbranch() to reject leading-dash values, unlike the Project, JobTemplate, and JobLaunch serializers. An attacker can set scmbranch to a value such as --upload-pack=/bin/id via the schedule or workflow node API. The injection is currently blocked by a runtime ValueError check in the task layer, but the API validation gap creates a latent risk if that defense-in-depth guard is ever refactored away.

A flaw was found in automation-controller. RunAdHocCommand.buildargs() appends the limit field as a bare positional argument instead of using the -l flag prefix as RunJob does. An attacker can set the limit field to a value beginning with a dash, which is then parsed as an ansible CLI option. The impact is currently limited to short-circuit flags such as --version and --help because the injected element displaces the required pattern positional argument.

A flaw was found in automation-controller. The LaunchConfigurationBaseSerializer used by Schedule and WorkflowJobTemplateNode does not implement ▎ validatescmbranch() to reject leading-dash values, unlike the Project, JobTemplate, and JobLaunch serializers. An attacker can set scmbranch to a value such as --upload-pack=/bin/id via the schedule or workflow node API. The injection is currently blocked by a runtime ValueError check in the task layer, but the API validation gap creates a latent risk if that defense-in-depth guard is ever refactored away.

A flaw was found in automation-controller. The notification template Jinja whitelist only inspects static Getattr AST nodes. An attacker with notification template admin privileges can bypass the whitelist using dynamic subscript expressions or conditional gating on runtime values that differ from the test-render stub. Exceptions raised during notification rendering write full Python tracebacks into the notification body, which is sent to the attacker-controlled webhook URL, leaking install paths, Python version, and source file line numbers.

A flaw was found in automation-controller. RunAdHocCommand.buildargs() appends the limit field as a bare positional argument instead of using the -l flag prefix as RunJob does. An attacker can set the limit field to a value beginning with a dash, which is then parsed as an ansible CLI option. The impact is currently limited to short-circuit flags such as --version and --help because the injected element displaces the required pattern positional argument.

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local OOB Read in NSS Service Request Parsers (sssnssprotocolparsesvcname / sssnssprotocolparsesvcport): malformed local service lookup requests can force parser reads beyond the declared packet body length and may crash the NSS responder. Requirements to exploit: Ability to run a local process that can connect to the NSS responder UNIX socket and send a crafted SSSNSSGETSERVBYNAME or SSSNSSGETSERVBYPORT request. In common NSS responder setups this is reachable by unprivileged local clients; deployments with stricter socket permissions or explicit UID restrictions reduce exposure. Component affected: sssd-2.12.0-1.el10 NSS responder, src/responder/nss/nssprotocol.c, sssnssprotocolparsesvcname(), sssnssprotocolparsesvcport() Version affected: sssd-2.12.0-1.el10 Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - 3.9 (LOW) AV:L - the attack requires local access to the NSS responder UNIX socket rather than remote network reachability. AC:L - constructing the malformed request body is straightforward and does not require special timing or heap shaping. PR:N - in common NSS responder deployments, an unprivileged local client can reach the socket and submit the request; tighter ACLs would reduce exposure. UI:N - no user interaction is required once the attacker can connect locally. S:U - the effect is confined to the SSSD responder process and its own security scope. C:N - the available evidence shows an invalid read, but not a returned or otherwise usable memory disclosure. I:N - no integrity impact has been demonstrated. A:L - the bug can trigger invalid reads and plausibly crash the responder, but reliability is not established and may depend on allocator layout. Impact: Low. Under the currently established facts, this is a local-only parser bug and the demonstrated effect is an out-of-bounds read with limited, non-deterministic availability impact in the NSS responder. The available evidence does not show privilege escalation, arbitrary code execution, or reliable disclosure of protected data. Under Red Hat's guidance, that best fits Low impact. Embargo: no Reason: The currently established impact is a local responder-side invalid read with at most limited denial-of-service potential. Given the low severity, straightforward validation fix, and absence of demonstrated confidentiality or integrity impact, embargoed handling does not appear necessary. Acknowledgement: Aisle Research Vulnerability Details: This is an input-validation flaw in the NSS responder service-query parsing path. sssnssprotocolparsesvcname() assumes the body contains two consecutive NUL-terminated strings within the declared body length. For a malformed GETSERVBYNAME request whose body is only b"a\x00" (blen == 2), the first scan stops at body[1], and the second scan immediately evaluates body[i + 1] as body[2], which is outside the declared body. c ssspacketgetbody(pctx->creq->in, &body, &blen); / If not terminated fail. / if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated\n"); return EINVAL; } / Calculate service name length. / for (i = 0, namelen = 0; body[i] != '\0'; i++) { namelen++; } / Calculate protocol name length, use index from previous cycle. / for (protocollen = 0; body[i + 1] != '\0'; i++) { protocollen++; } sssnssprotocolparsesvcport() similarly trusts that the request body is large enough to contain the fixed-size port and padding fields plus a trailing protocol string. It advances the body pointer by 2 sizeof(uint16t) + sizeof(uint32t) without first checking that blen is large enough, and then scans for a NUL terminator from the advanced pointer. c ssspacketgetbody(pctx->creq->in, &body, &blen); / If not terminated fail. / if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated\n"); return EINVAL; } SAFEALIGNCOPYUINT16(&port, body, NULL); port = ntohs(port); / Move behind the port and padding to get the protocol. / body = body + 2 sizeof(uint16t) + sizeof(uint32t); / Calculate protocol name length. / for (protocollen = 0, i = 0; body[i] != '\0'; i++) { protocollen++; } These parsers are reachable through the SSSNSSGETSERVBYNAME and SSSNSSGETSERVBYPORT command handlers. Under ASan or Valgrind, the malformed requests above produce invalid-read reports in the parser path. On non-instrumented builds, responder termination is plausible but not fully deterministic because the read may remain inside allocator slack rather than fault immediately. Steps to reproduce: 1. Build and run SSSD with ASan, or run the NSS responder under Valgrind, so the invalid read is reported deterministically. 2. Connect to the NSS responder UNIX socket, typically /var/lib/sss/pipes/nss. 3. Send one packet with the normal 16-byte SSSD header (len, cmd, status, reserved) followed by a malformed service lookup body. 4. For SSSNSSGETSERVBYNAME (0x00A1), use body b"a\x00" so only one NUL-terminated string is present. 5. For SSSNSSGETSERVBYPORT (0x00A2), use an 8-byte body such as b"\x00\x50\x00\x00\x00\x00\x00\x00" so the parser advances past the declared body and then scans for a terminator. 6. Observe the invalid read in sssnssprotocolparsesvcname() or sssnssprotocolparsesvcport() in the sanitizer or Valgrind output. A crash is possible, but may not occur on every run without instrumentation. Mitigation: Restrict access to the NSS responder UNIX socket to trusted local clients where feasible. Deployments that already enforce tighter socket permissions or explicit UID restrictions reduce exposure, but the parser bug remains until bounds checks are added. Proposed Fix: Reject zero-length or undersized bodies before dereferencing or advancing into the request, and bound each string scan by the declared body length. diff diff --git a/src/responder/nss/nssprotocol.c b/src/responder/nss/nssprotocol.c — a/src/responder/nss/nssprotocol.c +++ b/src/responder/nss/nssprotocol.c @@ -270,6 +270,10 @@ sssnssprotocolparsesvcname(struct clictx clictx, ssspacketgetbody(pctx->creq->in, &body, &blen); + if (blen == 0) { + return EINVAL; + } + / If not terminated fail. / if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated\n"); @@ -277,12 +281,20 @@ sssnssprotocolparsesvcname(struct clictx clictx, } / Calculate service name length. / for (i = 0, namelen = 0; body[i] != '\0'; i++) { + for (i = 0, namelen = 0; i < blen && body[i] != '\0'; i++) { namelen++; }

+ if (i >= blen || i + 1 >= blen) { + return EINVAL; + } + / Calculate protocol name length, use index from previous cycle. / for (protocollen = 0; body[i + 1] != '\0'; i++) { + for (protocollen = 0; (i + 1) < blen && body[i + 1] != '\0'; i++) { protocollen++; } + + if (i + 1 >= blen) { + return EINVAL; + } @@ -326,6 +338,10 @@ sssnssprotocolparsesvcport(struct clictx clictx,

ssspacketgetbody(pctx->creq->in, &body, &blen); + if (blen < (2 sizeof(uint16t) + sizeof(uint32t) + 1)) { + return EINVAL; + } + / If not terminated fail. / if (body[blen - 1] != '\0') { DEBUG(SSSDBGCRITFAILURE, "Body is not null terminated\n"); @@ -336,10 +352,15 @@ sssnssprotocolparsesvcport(struct clictx clictx, / Move behind the port and padding to get the protocol. / body = body + 2 sizeof(uint16t) + sizeof(uint32t); + blen -= 2 sizeof(uint16t) + sizeof(uint32t); / Calculate protocol name length. / for (protocollen = 0, i = 0; body[i] != '\0'; i++) { + for (protocollen = 0, i = 0; i < blen && body[i] != '\0'; i++) { protocollen++; } + + if (i >= blen) { + return EINVAL; + }

------ This report was generated using AI technology. Always review AI-generated content prior to use

Low: libxml2 security update

Low: libxml2 security update

original reporting: https://docs.google.com/document/d/1Rf4NtLudECimDNy8F9clUblm6Avx8yF/edit

Auth Bypass — Elytron OAuth2 introspection bearer param-injection enables cross-audience token swap (JBoss EAP)

Authentication bypass on any EAP application whose security domain is backed by an Elytron token-realm with <oauth2-introspection>. findings/jboss-eap111.md

Low: libarchive security update

AIONLYREPORT package: cockpit-356-1.el10 ------ Summary: Integer overflow in dolastlog() offset calculation can misaddress lastlog entries on ILP32 builds: a specially provisioned authenticated user can wrap the computed offset and cause cross-user reads and writes in legacy lastlog records during login accounting. Requirements to exploit: An authenticated account that can log in through Cockpit, a sufficiently large assigned UID to overflow uid sizeof(struct lastlog) on an ILP32 build, and a deployment where the cockpit-session path updates legacy /var/log/lastlog. Component affected: cockpit-356-1.el10, src/session/session-utils.c, dolastlog() in the cockpit-session login-accounting path Version affected: cockpit-356-1.el10; reachability is limited to ILP32 deployments where cockpit-session updates legacy /var/log/lastlog entries Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N - 3.6 (LOW) AV:L - Exploitation requires control of a locally provisioned account on the target system that is permitted to authenticate through Cockpit. AC:H - Exploitation additionally depends on uncommon but valid preconditions: an ILP32 build, legacy /var/log/lastlog handling being active, and a sufficiently large UID that causes wraparound. PR:L - The attacker needs a valid low-privilege account. UI:N - No separate victim interaction is required after the attacker authenticates. S:U - The impact remains within the same system scope that performs login accounting. C:L - A wrapped read can disclose another account's lastlog entry. I:L - A wrapped write can alter another account's lastlog entry, including the demonstrated UID 0 slot. A:N - The available evidence shows misaddressed login-accounting data, not direct service disruption. Impact: Low. Based on Red Hat severity guidance, this issue fits Low impact because exploitation depends on unlikely but technically valid circumstances and the demonstrated consequences are limited to confidentiality and integrity of legacy lastlog metadata. The available evidence does not show code execution, privilege escalation, or broader system compromise. Embargo: no Reason: The supported impact is low and configuration-dependent, and the issue is limited to lastlog record disclosure and tampering rather than system compromise. Acknowledgement: Aisle Research Vulnerability Details: In dolastlog(), the file offset used for both pread() and pwrite() is computed as uid sizeof entry without an overflow check or a guaranteed widened intermediate type. On ILP32 builds, that multiplication can wrap before being passed as an offt, redirecting access to a different user's slot in /var/log/lastlog. c r = pread (fd, &entry, sizeof entry, uid sizeof entry); ... r = pwrite (fd, &entry, sizeof entry, uid sizeof entry); For example, when sizeof(struct lastlog) = 292, uid = 1073741824 wraps the product to 0, which targets UID 0's record. The available evidence indicates this path is reached from utmplog() during authenticated cockpit-session login handling, so a successful login by a specially provisioned high-UID account can cause cross-user lastlog reads and writes in privileged session-accounting code. Steps to reproduce: 1. Use an ILP32 environment, such as a 32-bit userspace/build, where the uid sizeof entry multiplication is evaluated in 32-bit width. 2. Ensure Cockpit uses the cockpit-session login path and that /var/log/lastlog exists. 3. Create or identify an account with a UID that causes wraparound, such as 1073741824 when sizeof(struct lastlog) = 292. 4. Record the current UID 0 entry with lastlog -u 0. 5. Log in through Cockpit as the high-UID account. 6. Re-run lastlog -u 0 and observe that the UID 0 entry changed. 7. Optionally trace pread() and pwrite() in dolastlog() and confirm the wrapped offset, 0 in this example. Mitigation: If cockpit-356-1.el10 is deployed in an affected ILP32 configuration, avoid assigning unusually large UIDs to accounts that can authenticate through Cockpit, and restrict such accounts from the cockpit-session login path until a fix is available. Proposed Fix: Compute the lastlog offset once in checked offt space, reject overflow before I/O, and use the verified offset for both operations. diff diff --git a/src/session/session-utils.c b/src/session/session-utils.c index XXXXXXX..YYYYYYY 100644 — a/src/session/session-utils.c +++ b/src/session/session-utils.c @@ -6,6 +6,7 @@ #include "session-utils.h" #include "common/cockpitframe.h" +#include <limits.h> #include "common/cockpitjsonprint.h" #include "common/cockpitmemory.h" @@ -194,6 +195,18 @@ dolastlog (uidt uid, bool result = false; int fd = -1; ssizet r; + offt offset; + + if ((uintmaxt) uid > ((uintmaxt) OFFMAX / (uintmaxt) sizeof entry)) + { + warnx ("uid %u causes lastlog offset overflow", (unsigned) uid); + goto out; + } + + offset = (offt) uid (offt) sizeof entry; + if (offset < 0) + goto out; @@ -207,7 +220,7 @@ dolastlog (uidt uid, r = pread (fd, &entry, sizeof entry, uid sizeof entry); + r = pread (fd, &entry, sizeof entry, offset); @@ -277,7 +290,7 @@ dolastlog (uidt uid,

r = pwrite (fd, &entry, sizeof entry, uid sizeof entry); + r = pwrite (fd, &entry, sizeof entry, offset);

------ This report was generated using AI technology. Always review AI-generated content prior to use

A vulnerability was found in the netavark package, a network stack for containers used with Podman. Due to dns.podman search domain being removed, netavark may return external servers if a valid A/AAAA record is sent as a response. When creating a container with a given name, this name will be used as the hostname for the container itself, as the podman's search domain is not added anymore the container is using the host's resolv.conf, and the DNS resolver will try to look into the search domains contained on it. If one of the domains contain a name with the same hostname as the running container, the connection will forward to unexpected external servers.

Netavark was recently changed, when being used with podman, to remove the dns.podman search domain in detriment of using the host's search domain in the container. This leads to a possible DNS resolve confusion in some scenarios where the container created using podman have the same hostname as an external service. This may lead to containers communicating to unexpected servers instead of the desired one.

A flaw was found in Keycloak. The Keycloak guides recommend to not expose /admin path to the outside in case the installation is using a proxy. The issue occurs at least via ha-proxy, as it can be tricked to using relative/non-normalized paths to access the /admin application path relative to /realms which is expected to be exposed.

Low: mingw-openssl security update

Low: httpd security update

A stack buffer overflow exists in 389 Directory Server's checkPrefix() function (pw.c:440-466). When parsing reversible-encrypted attribute values in the format {SCHEME-<algid>}ciphertext, the algorithm ID is copied into a 256-byte stack buffer via memcpy with no bounds check on (end - delim).

An attacker with Directory Manager privileges can crash ns-slapd by storing a crafted nsDS5ReplicaCredentials (or similar reversible-encrypted config attribute) with an oversized algorithm ID. FORTIFYSOURCE (memcpychk) aborts the process before overflow bytes are written, limiting impact to DoS (SIGABRT) only. Code execution is not possible on production builds.

Production crashes confirmed on RHEL 7 (389-ds-base-1.3.11.1-5.el79) and Fedora 42 (389-ds-base-3.1.4-6.fc42). RHEL 8 crash confirmed via dse.ldif injection (389-ds-base-1.4.3.39-2.moduleel8).

Note: cn=config is local configuration and not replicated; triggering requires Directory Manager access on the target server.

Advisory: 389-ds-campaign-2026-04/003-Stack-Overflow-checkPrefix/advisory.md. Source: PSIRTSUPT-7600 (Ian Murphy, Red Hat Product Security).

Improper input validation vulnerability in Keycloak related to the handling of matrix parameters in URL paths. The issue occurs because Keycloak, via its JAX-RS routing layer, accepts RFC-compliant matrix parameters (e.g., ;param) in path segments, while common reverse proxy configurations may ignore or mishandle them when enforcing access restrictions. A remote attacker can craft requests such as /realms;abc/master/account to mask path segments and bypass proxy-level path filtering. Although authentication is still required, this may expose administrative or sensitive endpoints that operators believe are not externally reachable. Exploitation is network-based, requires no authentication, and depends on the reverse proxy configuration in front of Keycloak.

A flaw was found in Keycloak in the OAuth 2.0 Pushed Authorization Requests (PAR). Client provided parameters were found to be included in plain text in the KCRESTART cookie returned by the authorization server's HTTP response to a requesturi authorization request. This could lead to an information disclosure vulnerability.

A vulnerability was found in Wildlfly management interface where there is no sockets limits to perform connections to http management interface. This may lead occasionally to a Denial of Service (DoS) for Wildfly server after nofile limit reaches its maximum. This requires normally local access as the management interface is not exposed by default and it is not a common configuration to make it public.

Low: php8.4 security, bug fix, and enhancement update

An incomplete fix for CVE-2026-9689 was identified in Keycloak's RedirectUtils.containsForbiddenOidcParameters() method. While the original fix successfully blocks forbidden OIDC parameters (such as code, state, and iss) in the URI query string, it fails to inspect the URI fragment (#). When a client is configured with a wildcard redirect URI, an attacker can supply a redirecturi containing these forbidden parameters within the fragment. Because matchesRedirects strips fragments during prefix matching, the crafted URI is accepted. During the authorization response, Keycloak appends its own parameters to the attacker-supplied fragment, leading to a polluted response where attacker-controlled values appear first. Exploitation Conditions: The target client must have a wildcard-registered redirect URI (e.g., https://app.example.com/).

The attacker must induce a victim to follow a crafted authorization URL.

The relying party (client application) must use a first-wins parsing strategy for duplicate parameters.

Concrete Impact: Injection of attacker-controlled iss (issuer), state, and accesstoken parameters.

Potential for session fixation or account confusion if the relying party does not validate parameters per RFC 9207.

Low: php:8.3 security, bug fix, and enhancement update

Low: php:8.2 security, bug fix, and enhancement update

Low: php:7.4 security, bug fix, and enhancement update

A flaw was found in Keycloak’s CIBA feature where insufficient validation of client-configured backchannel notification endpoints could allow blind server-side requests to internal services.

A flaw was found in pki-core. In the Dogtag/pki-core Certificate Authority (CA) profile framework, the certificate enrollment path (EnrollmentProcessor) calls AuthzSubsystem.checkRealm() to verify that the calling principal is authorized to act within the request's configured realm before the request is submitted. The certificate renewal path (RenewalProcessor), which is reachable from the same public REST endpoint (caProfileSubmit, and the legacy v1/CertRequestDAO and ProfileSubmitServlet entry points) and is selected purely by a client-controlled 'isRenewal' flag in the posted request body, runs the same populate-then-submit sequence and stamps the same realm onto the request via the shared AuthzRealmDefault policy default, but never calls checkRealm. As a result, a caller who is only entitled in realm A can submit a renewal naming the serial number of a certificate originally issued under realm B; the renewal request is repopulated with realm B and submitted to realm B's request queue without realm B's authorization manager ever being consulted. This was dynamically reproduced end-to-end in an isolated sandbox: an identity with zero entitlement to a configured realm, freshly confirmed denied on the equivalent enrollment call, successfully renewed another user's certificate in that realm via a single authenticated request, with checkRealm never invoked. Direct testing established the practical impact is narrower than a realm-authorization bypass might suggest: the resulting certificate's content is already retrievable by any unauthenticated caller via the product's own intended read API, confirmed both same-host and across a genuine cross-container network boundary (no net-new confidentiality exposure); no private key material is ever exposed (no impersonation path); and the victim's own certificate and their own ability to renew it are both completely unaffected (no denial-of-service capability via revocation, side-effects, or resource exhaustion -- all tested directly). Attack Complexity is assessed High because exploitability additionally requires a non-default, supported deployment configuration (a realm-mapped authorization manager, the multi-realm/delegated-CA deployment mode), per Red Hat's documented CVSS scoring practice for configuration-dependent flaws. This affects the Dogtag PKI CA codebase across all current Red Hat package names for it: pki-core (RHEL 6-9, Certificate System 9), dogtag-pki (RHEL 10, RHIVOS 2, Fedora), and redhat-pki (Certificate System 10/11) -- the same missing checkRealm call was independently confirmed present in EnrollmentProcessor and absent from RenewalProcessor at the exact upstream versions shipped as dogtag-pki 11.9.0 and redhat-pki 11.10.0, not merely inferred from shared upstream provenance. Git history analysis shows the gap was introduced by omission in commit e2de26769761af04b9c56071bd1a1926903c49b6 (2016-05-09), which added the realm check only to EnrollmentProcessor roughly 63 hours after a separate commit had modified both EnrollmentProcessor and RenewalProcessor symmetrically at the same code location -- indicating an oversight rather than an intentional design decision.

Low: php:8.2 security, bug fix, and enhancement update

Capstone is a disassembly framework with the target of becoming the ultimate disasm engine for binary analysis and reversing in the security community.Security Fix(es): capstone: Capstone: Memory corruption via unchecked vsnprintf return (CVE-2025-68114) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.