A flaw was found in sequoia-openpgp. The library incorrectly infers key flags for older certificates when a key flags subpacket is missing, leading to a discrepancy in how key capabilities are viewed. This key flag confusion allows an attacker to bypass the back-signature check. Consequently, an attacker can illegitimately bind an arbitrary subkey to their own certificate and forge signatures, completely compromising cryptographic integrity.

A flaw was found in crass. A remote attacker can cause a Denial of Service (DoS) by submitting specially crafted Cascading Style Sheets (CSS) inputs containing scientific notation with excessively large exponents. Because crass calculates these exponent values without proper limits, processing the input can exhaust system CPU and memory resources, potentially causing the application to crash.

A flaw was found in crass. A remote attacker can cause a Denial of Service (DoS) by submitting a specially crafted stylesheet containing a large number of adjacent comments. Because the parser recursively processes comments when discarding them, handling these consecutive comments triggers excessive recursion that crashes the application.

A flaw was found in Puma. An attacker could exploit a vulnerability within the HTTP parser component to execute arbitrary code. This could allow the attacker to take control of the affected system.

A flaw was found in Foreman. The template revision endpoint does not enforce object-level authorization when retrieving an audited template revision. An authenticated, low privileged user with a template-related permission, such as view_ptables, can obtain historical template contents belonging to another organization or location by supplying the corresponding audit ID. This can result in unauthorized disclosure of historical template contents, which may contain sensitive configuration information, credentials, or other secrets. The REST API revision endpoints correctly restrict this lookup.

A flaw was found in Katello where the Content View Filter Rules API does not properly enforce authorization on the parent Content View Filter. An authenticated, low-privileged user with Content View permissions in one organization may be able to access and modify filter rules belonging to a Content View Filter in another organization by supplying that filter's identifier. This can result in unauthorized disclosure of filter-rule information and unauthorized changes to unpublished Content View filter configuration.

A flaw was found in ansible-core's ansible.builtin.git module. The module invokes git (ls-remote, clone, fetch) with the repository URL as a positional argument and without a "--" separator, so a repository URL that begins with a dash is interpreted by git as a command-line option. A caller that passes an attacker-controlled repository URL to the module can trigger argument injection (for example --upload-pack/--exec), resulting in arbitrary command execution on the host running the module.

A flaw was found in Foreman’s Api::V2::PersonalAccessTokensController, where Foreman::Controller::UserAware#find_user resolves the target account using User.find(params[:user_id]) without applying the required parent-user authorization check. An attacker with the create_personal_access_tokens permission can therefore invoke POST /api/v2/users/:user_id/personal_access_tokens with another user’s ID and create a Personal Access Token on their behalf. The resulting plaintext token is returned in the API response, while PersonalAccessToken#check_permissions_after_save only validates create_personal_access_tokens on the token and does not enforce edit_users authorization on the target user. The attacker can then use the forged token to authenticate as the victim, potentially resulting in complete account takeover, including administrator accounts.

A flaw was found in Foreman’s Api::V2::MailNotificationsController, where authorization checks on user-specific mail-notification resources are insufficient. The GET /api/v2/users/:id/mail_notifications endpoint resolves the target account using User.find(params[:id]) without verifying that the authenticated user is authorized to access that user’s notification configuration. Additionally, the POST and PUT /api/v2/users/:user_id/mail_notifications paths call deny_access when the requester is unauthorized but fail to halt execution, allowing the request to continue and persist the unauthorized change despite a 403 response or subsequent DoubleRenderError. This can allow a user to disclose another user’s mail-notification configuration, including mail_query values, and, where write permissions apply, modify or create notification settings for another user.

A flaw was found in Foreman’s Api::V2::SshKeysController, where the target user is resolved through Foreman::Controller::UserAware#find_user using User.find(params[:user_id]) without enforcing the required parent-user authorization check. An attacker with the create_ssh_keys permission can exploit this authorization bypass by submitting POST /api/v2/users/:user_id/ssh_keys with another user’s ID and injecting their own public SSH key into the targeted account. The injected key is subsequently propagated to hosts provisioned by that user, potentially allowing the attacker to authenticate to and gain SSH access to the victim’s managed hosts.

A path traversal vulnerability was found in pulpcore. The content upload API accepts a 'file_url' parameter that allows users with file repository privileges to specify a local file URL for Pulp to download and store. A URL scheme validation check uses a string prefix comparison that only rejects URLs beginning with 'file://', but Python's URL parser recognizes the 'file:' scheme without double slashes, creating a mismatch between what is validated and what is dispatched to the file downloader. An authenticated user with low-privilege repository permissions can supply a specially crafted URL using relative path traversal sequences to read any file accessible to the Pulp server process. In deployments that include Pulp Container, successful exploitation allows an attacker to read the container registry token signing private key and forge bearer tokens, granting unauthorized access to all private container repositories in the affected registry.

A flaw was found in PyJWT. When retrieving cryptographic keys from a JSON Web Key Set (JWKS) endpoint, PyJWKClient fails to validate HTTP redirect destinations against trusted domain boundaries. A remote attacker who can influence the response of a trusted endpoint can redirect key requests to an untrusted server, allowing the client to accept forged verification keys or potentially exposing sensitive credentials.

A flaw was found in PyJWT. When an application allows both symmetric and asymmetric signing algorithms, minor formatting variations in a public key can prevent the library from properly identifying it as an asymmetric key. Consequently, the library improperly treats the public key as a shared secret key, allowing a remote attacker to forge valid authentication tokens and bypass security controls.

A flaw was found in pyjwt. When verifying cryptographic keys, the raw JSON Web Key (JWK) parser fails to normalize Unicode byte-order marks (BOM). In mixed-algorithm verification environments, an attacker who knows the public key can supply a key prefixed with a byte-order mark, causing the system to misidentify the public key as a shared symmetric secret. This flaw allows an attacker to forge authenticated JSON Web Tokens (JWT) and bypass authentication controls.

A flaw was found in PyJWT. This vulnerability allows an unauthenticated remote attacker to bypass authentication by forging arbitrary JSON Web Tokens (JWTs). When an application allows both symmetric and asymmetric algorithms, PyJWT fails to properly validate public JSON Web Key (JWK) container representations, mistakenly accepting public key material as a symmetric Hash-based Message Authentication Code (HMAC) secret. As a result, an attacker with knowledge of the public key can generate validly signed tokens with arbitrary authenticated claims.

A flaw was found in pulp-rpm when it publishes a distribution tree. Addon and variant ids from .treeinfo are used as directory names. A user who can sync or upload that tree can make the publish task create a new directory outside the task work area and write that tree's repository metadata and packages there, as the Pulp worker user. An existing file or directory is not replaced. The flaw does not disclose data and does not stop the service.