Tanguy Snoeck

Instances configured to require TOTP enrolment via `Security.otp required` only enforced mandatory two-factor authentication for standard browser requests. Authenticated users who had not enrolled in TOTP could bypass this requirement by using non-browser request types, such as AJAX/XHR calls, REST API requests, `.json` format URLs, `restSearch` queries, or automation actions. This occurs because machine-readable requests cannot follow the redirect to the TOTP enrolment page, allowing the user to maintain full access to the instance without completing the second-factor setup.

A flaw exists in the one-time password (OTP) authentication flow that allows the replay of a consumed HMAC-based One-Time Password (HOTP) token and the rewinding of the token counter. The issue occurs because the verification logic compares the submitted token against a counter value cached in the user session instead of the authoritative counter in the database. Since the cached counter is not updated after a token is used, an attacker with a valid session (where the password has been submitted but the OTP is pending) can reuse a previously used token to bypass the second authentication factor and gain unauthorized access. This process also corrupts the HOTP counter state, which may invalidate future legitimate tokens.

A flaw in the two-factor authentication (TOTP) verification process allows a valid one-time code to be accepted multiple times within its time-based validity window, typically 30 seconds. This occurs because the system fails to record if a specific TOTP period has already been consumed. An attacker who intercepts a legitimate code during a user login can replay it to establish an unauthorized second session as that user, potentially compromising administrative functions and threat-intelligence data.

A tenant isolation bypass exists in the semantic cache layer due to a metadata key mismatch between the ` get semantic cache tenant scope()` and ` get metadata variable name()` functions. Authenticated users with a valid virtual key can exploit this by submitting semantically similar prompts to the '/v1/responses' and '/bedrock/*' endpoints. This allows an attacker to retrieve cached responses belonging to other tenants, potentially exposing personally identifiable information, financial data, or source code. Additionally, this can lead to the execution of attacker-supplied tool calls under victim credentials if cached `function call` or `tool calls` payloads are returned to a different principal.

An unsafe deserialization issue exists in the registry server that allows unauthenticated or unauthorized attackers to achieve remote code execution. By sending a crafted gRPC request, an attacker can exploit the `user defined function.body` field of an OnDemandFeatureView spec. This field is base64-decoded and passed to the `dill.loads()` function before any authorization checks occur. This allows the embedding of a malicious serialized Python object with an arbitrary ` reduce ` method to execute OS commands under the privileges of the feast service account.

An issue exists where unauthenticated attackers can restore and inherit authenticated user sessions. This occurs during WebSocket session restoration when a valid `sessionId` is presented without ownership verification via the 'restore existing session' path. Successful exploitation allows an attacker to assume a victim's permissions and roles, leading to unauthorized access to restricted data and the ability to invoke tools.