CVE Vulnerability Catalog

Prior to version 2.57.0 of Kimai, the PATCH /api/timesheets/{id} and POST /api/timesheets endpoints accepted a user-controlled project identifier that bypassed team access criteria. Any authenticated user with edit_own_timesheet could assign an owned timesheet to a project outside the user's teams, persist unauthorized project attribution, and retrieve project and customer metadata through GET /api/timesheets/{id}?full=true.

Prior to version 2.57.0 of Kimai, the GET /api/timesheets list endpoint accepted user identifiers from a caller with view_other_timesheet but did not verify that a ROLE_TEAMLEAD requester leads a team containing each target user. This allowed a teamlead to retrieve another user's descriptions, timing data, tags, rate, and internalRate even though GET /api/timesheets/{id} would deny access.

Improper handling of insufficient permissions or privileges in Secomea GateManager allows privilege escalation. Affected versions are 11.5;0 and 11.4.625515072:0. Fixed in version 11.6 or 11.4.626194074 and above.

A session fixation vulnerability in the Secomea GateManager webserver module allows session fixation. This issue affects GateManager versions 11.5;0 and 11.4.625515072:0. It is fixed in version 11.6 or 11.4.626194074 and above.

Affected versions of MISP up to 2.5.45 can record incorrect access-log data for requests that terminate in an exception. Because CakeErrorController extends AppController, exception rendering runs the application startup path a second time, causing AccessLog::logRequest() to be called twice for one HTTP request. The second write can overwrite the row created by the first, corrupting request duration, SQL query count, memory usage, and potentially the query log.

Affected versions of MISP up to 2.5.45 expose several state-changing controller actions without restricting them to POST. These actions include purgeUnusedPictures(), enableNoticelist(), removeOrphanedCorrelations(), and rebuildRedis(). An attacker can trigger these actions via ordinary GET requests, using an authenticated victim's session, potentially leading to unauthorized changes.

In OpenAM prior to 16.1.2, the pre-authentication /authservice PLL endpoint accepts a CustomCallback XML element whose className value selects an arbitrary Java class for AuthXMLUtils to load and instantiate without verifying it implements DSAMECallbackInterface. Default configurations expose the endpoint without authentication, allowing attacker-controlled class initialization and unsafe deserialization to execute code in the server process. Enabling sunRemoteAuthSecurityEnabled does not prevent the vulnerable parsing because its check occurs later.

OpenAM from version 13.0.0 to 16.1.2 has a reflected XSS vulnerability in the OAuth2 authorize endpoint's display=wap consent page. The page reflects request-derived values without HTML escaping, allowing an attacker to execute JavaScript in the OpenAM origin, enabling session or cookie theft, CSRF-token disclosure, and actions with the victim's privileges. At least one registered OAuth2 client is required, but the attacker does not need to control that client.

In OpenAM prior to 16.1.2, WebAuthnAuthentication.deserialize applies an ObjectInputFilter that allows every serialized object at depth greater than 1, constraining only an AuthenticatorImpl root object. A pre-authentication attacker can supply a userHandle whose serialized graph has a valid AuthenticatorImpl root and a nested gadget class, causing readObject or readResolve execution before cast and assertion verification. This bypasses the incomplete remediation for the earlier WebAuthn deserialization vulnerability.

A vulnerability exists in the Sealed Secrets controller's unauthenticated POST endpoints /v1/verify and /v1/rotate. An attacker with internal network access can inject custom Go template logic into spec.template.data and use differential HTTP response codes (200 vs 409) as a decryption oracle to recover the full plaintext of any sealed secret. The issue is exacerbated by missing AEAD label binding for spec.template.data, allowing arbitrary modification of that field while keeping the ciphertext valid.

In OpenAM, the default configuration initializes the iPlanetDirectoryPro SSO cookie with HttpOnly disabled and without a protective SameSite default, and OAuth and OpenID Connect consent flows reuse that cookie through CsrfProtection as a CSRF token. When combined with same-origin cross-site scripting and a user following an attacker-controlled link, the cookie can be read and reused to steal the SSO session and complete attacker-driven consent grants. This issue is fixed in version 16.1.1.

In OpenAM prior to 16.1.1, AuthorizationCodeGrantTypeHandler requires a code_verifier only when the realm-wide codeVerifierEnforced setting is enabled, even when an authorization code stores a code_challenge. Because that setting is disabled by default, an attacker who intercepts a PKCE-protected authorization code can omit code_verifier and redeem the code. Public clients are directly affected, and confidential-client exploitation additionally requires client authentication material.

In OpenAM, the private_key_jwt client authentication path uses ClientJwksResolverCache without reliably binding a cached jwks_uri resolver and verified assertion to the expected clientID in ClientCredentialsReader. An attacker controlling any registered client with published keys, including one obtained through open dynamic registration when enabled, can authenticate as another client whose keys are exposed through jwks_uri and mint tokens in that client's name across realms in the same OpenAM process. This issue is fixed in version 16.1.1.

In OpenAM, GroovySandboxValueFilter permits an authenticated server-side script author to escape the scripting sandbox despite the default class allow and deny lists. A user such as a sub-realm RealmAdmin who can create or edit a script in an executed context can invoke operating-system commands as the OpenAM application server account, crossing the realm-scoped administration boundary and compromising the JVM and every realm it serves. This issue is fixed in version 16.1.1.

In OpenAM, the OAuth2 authentication module updates an existing local account with profile attributes that can include userPassword and inetUserStatus, rewriting the password to the username and reactivating disabled accounts. The missing OAuth.removeRestrictedAccountUpdateAttributes filtering permits these credential and status fields to reach the account update. With account creation enabled, repeated OAuth login causes the default ldapService chain to accept the username as both identifier and password, allowing an unauthenticated attacker to take over the local account without interacting with the identity provider. This issue is fixed in version 16.1.1.

In OpenAM prior to 16.1.1, MSISDNValidation in the MSISDN authentication module concatenates the request-supplied MSISDN value into an LDAP search filter without escaping, while the default empty trusted-gateway list allows all traffic. In a realm where an MSISDN module is enabled in a reachable authentication chain, an unauthenticated remote attacker can inject LDAP filter metacharacters, select an arbitrary matching user, and obtain a normal authenticated OpenAM session without a password.

In OpenAM, OAuthTokenStore reads caller-supplied token identifiers from the shared Core Token Store (CTS) without an OAuth-only namespace, and OAuthAdapter accepts a row whose BLOB claims to contain an OAuth token without binding the trusted CTS type or verifying integrity. An attacker who can place controlled JSON in CTS under a known token identifier, such as through Push Registration followed by an anonymous SNS callback in an enabled realm, can mint OAuth bearer tokens and OpenID Connect ID tokens with chosen subject, client, realm, and scope. This issue is fixed in version 16.1.1.

In OpenAM, the anonymous Push Notification SNS callback handled by SnsMessageResource falls back to a CTS predicate blob after a messageId expires from the in-memory dispatcher, treats top-level blob keys as Java class names for Class.forName, and deserializes attacker-controlled JSON through Jackson. A low-privileged user who starts Push Registration and obtains the messageId, shared secret, and challenge can wait for expiry, replace the persistent blob through anonymous callbacks, and trigger class loading and construction in the OpenAM JVM. This issue is fixed in version 16.1.1.

In OpenAM prior to 16.1.1, the Liberty Web Services SOAP receiver permits unauthenticated remote requests to write persistent entries through SOAPReceiver and DiscoveryService into a user's Liberty Discovery store and the shared root-realm Discovery branch. The server-side handlers bypass requester LDAP and identity ACLs, and the global path uses an internal administrative token. Deployments that consume Liberty discovery data can subsequently use manipulated service-routing or security-mechanism records.

In OpenAM prior to 16.1.1, WebAuthnAuthentication loads a serialized AuthenticatorImpl object graph from the configured userAttribute through loadAuthenticators without an ObjectInputFilter. Exploitation requires the WebAuthn flow to be reachable and an attacker to have previously written controlled data to that attribute through delegated administration, provisioning, directory access, legacy REST self-registration, or unsafe configuration. When those conditions hold, the data is deserialized before assertion verification and can execute a classpath gadget in the application server process.