| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Description
getTopologyPageInfo merged the Nimbus daemon configuration with the topology's own configuration and returned the result without redaction in the topology_conf field of TopologyPageInfo. The Storm UI copied that value verbatim into the configuration field of GET /api/v1/topology/{id} and of the corresponding metrics endpoint.
Where the cluster is configured with them, the merged map includes storm.zookeeper.auth.payload, which Storm's own documentation directs operators to keep in storm-cluster-auth.yaml under permissions that deny access from workers, together with the keystore and truststore passwords for the Thrift, Netty and ZooKeeper TLS configuration, and any plugin key whose name denotes a secret.
getTopologyPageInfo is a topology read-only operation. Under SimpleACLAuthorizer a principal listed in topology.readonly.users or topology.readonly.groups could therefore read daemon credentials that the dedicated cluster configuration API, getNimbusConf, redacts and that is gated on nimbus.users instead. The sibling operations that exist to serve configuration were masked; the topology page, which merges in strictly more daemon state, was not.
Mitigation
Upgrade to 3.1.0, where credential-bearing values are masked before any configuration is served over the Nimbus API.
Users who cannot upgrade immediately should remove any principal that is not trusted with cluster credentials from topology.readonly.users, topology.readonly.groups, topology.users and topology.groups, and should rotate the ZooKeeper authentication payload and any TLS keystore or truststore passwords that were reachable through the topology page.
Credit
Wanxin Yin (yaklang.io) reported this issue to the Apache Security Team. |
| Description
When ZooKeeper authentication is configured, Storm deliberately retains
`storm.zookeeper.topology.auth.payload` in the topology configuration, because workers need it. Nimbus then
served that configuration verbatim to any caller holding read-only topology permissions, so a user whose
only grant was the ability to view a topology received its ZooKeeper credential.
That credential is not read-only. The cluster state implementation uses write-capable ACLs for worker
heartbeats, backpressure and error state, so a recipient can forge or remove that state for the topology
concerned. It is not a write credential on assignments.
The same advisory covers the submission client, which logged the generated payload at INFO on every
submission that generated one, and the SASL handlers, which logged it at DEBUG. The credential therefore
also reached any log aggregation or support bundle collected from the cluster.
Mitigation
Upgrade to 3.1.0, where the payload is removed from the configuration served to read-only callers and is no
longer written to logs.
Users who cannot upgrade immediately should rotate `storm.zookeeper.topology.auth.payload` for existing
topologies, review retained logs and support bundles for the value, and restrict read-only topology
permissions to trusted principals.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| Description
`getNimbusConf` returned the complete daemon configuration without redaction after only a user-level
authorization check. Where the cluster is configured with them, that response includes
`storm.zookeeper.auth.payload` and the keystore and truststore passwords for the Thrift, Netty and
ZooKeeper TLS configuration. The project masks passwords elsewhere before display, so the omission here is
inconsistent rather than intended.
The UI endpoint `/api/v1/cluster/configuration` compounded this. It carried no `@AuthNimbusOp` annotation,
and the authorization filter treated a missing annotation as "no gate required" and returned immediately, so
the endpoint applied no per-user check at all and proxied the request under the UI daemon's own principal.
Any user able to pass `ui.filter` therefore received the full configuration, including principals that
Nimbus itself would have refused.
Mitigation
Upgrade to 3.1.0, where credential-bearing values are masked before the configuration is served and where
every UI API endpoint must declare its authorization explicitly.
Users who cannot upgrade immediately should place the UI behind an authenticating reverse proxy that
restricts `/api/v1/cluster/configuration`, and should rotate the ZooKeeper authentication payload and any
TLS keystore or truststore passwords that were reachable through it.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| Insufficiently Protected Credentials vulnerability in Apache Syncope.
Audit events, when sent to the configured store, are not sufficiently masked for the sensitive values they might carry on their payloads, thus allowing administrators to access such sensitive values.
This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2.
Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
| Affected versions of MISP’s interactive CLI shell implement access control independently from the normal web application, causing several authorization inconsistencies.
The patch shows that CLI access could differ from the web application in multiple security-sensitive areas:
- feed listings did not enforce the same lookup_visible restrictions for non-host-organisation users;
- feed detail access did not enforce the same host-organisation/site-admin authorization as FeedsController::view();
- Feed.headers, which can contain HTTP authorization credentials, could be exposed instead of being hidden or masked;
- server synchronization authkey values were not explicitly hidden from CLI detail output;
- sharing-group detail access did not consistently use SharingGroup::checkIfAuthorised();
- the use command could establish context for a record without first proving that the user was authorized to view that record
The commit additionally hardens pagination and terminal rendering, including neutralization of terminal control sequences found in database-backed values. Those are important hardening changes, but the main vulnerability is the CLI authorization/data-disclosure mismatch.
Version affected: ≤2.5.45 |
| CWE-522: Insufficiently Protected Credentials vulnerability that could result in exposure of authentication information and unauthorized access to RTU functionality. |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: use cifs_invalidate_cache() in cifs_do_truncate() for O_TRUNC
cifs_do_truncate() is invoked from cifs_open() without i_rwsem, so it
cannot use cifs_resize_file_locked() to perform a proper fscache cookie
resize. Instead, add cifs_invalidate_cache() after cifs_setsize().
cifs_invalidate_cache() calls fscache_invalidate(), which works without
holding i_rwsem: it unconditionally increments inval_counter and sets
FSCACHE_COOKIE_NO_DATA_TO_READ, ensuring that stale cached data is not
served once the cookie is later activated by fscache_use_cookie().
Truncation to zero leaves no valid cached data, making invalidation the
correct semantic here. |
| IBM Netezza Software 11.3.0.3 through Interim Fix 002 has credentials that are hardcoded in the application source code, allowing unauthorized access to the container registry. The exposed secret enables attackers to pull private container images, potentially revealing proprietary code, configuration details, and other sensitive information. |
| MISP contains an authentication bypass vulnerability in its LDAP and LinOTP authentication components due to insufficient validation of user-supplied credentials.
The custom LdapAuthenticate and LinOTPAuthenticate components replace CakePHP's FormAuthenticate implementation but did not replicate its credential validation checks. As a result, empty or non-string values could reach the underlying authentication mechanisms.
In the LDAP authentication path, an attacker able to identify a valid directory user's email address could submit an empty password. The empty credential could be passed to ldap_bind(), where an LDAP server accepting unauthenticated binds may return a successful result for a valid distinguished name combined with an empty password. MISP could consequently treat the attacker as the corresponding authenticated directory user without verification of the user's password.
The issue also affected the LinOTP authentication component. Invalid credential types were not rejected before being processed, and when mixed authentication was enabled, an empty password could be checked against a locally stored MISP password hash. LDAP-provisioned MISP accounts could additionally be created with an empty local password because account creation skipped normal validation, resulting in a hash corresponding to an empty password. This could permit authentication through the local fallback mechanism when such an account was no longer resolved through LDAP.
Successful exploitation could allow a remote unauthenticated attacker to impersonate an existing MISP user. If the targeted account has administrative or other privileged permissions, the attacker could gain corresponding access to sensitive threat-intelligence data, modify or delete information, alter configuration, or perform other privileged operations.
The patch resolves the vulnerability by requiring authentication identifiers and passwords to be valid strings, rejecting empty passwords where they are not explicitly permitted, and assigning a randomly generated local password to LDAP-provisioned accounts instead of storing a hash derived from an empty password. |
| A vulnerability exists in the Credential Manager component that may allow for unauthorized administrative access. An unauthenticated remote attacker could exploit this vulnerability on a device in its factory-default or post-ZTP state before any administrator has configured credentials by providing a predictable factory-default password. Successful exploitation could result in full administrative control of the affected device during the initial setup process. |
| In affected Snowflake drivers, WORKLOAD_IDENTITY authentication requests a cloud workload-identity token and attaches it to the login request without verifying that the configured host is a Snowflake endpoint. An attacker who can modify the connection configuration can cause the driver to mint a fresh attestation and send it to a host they control. The captured token can be replayed to Snowflake for its remaining lifetime in accounts where that workload identity is already registered. On Azure, the token audience is also taken from connection configuration. Combined with an attacker-controlled host, the driver can request a Managed Identity access token scoped to a non-Snowflake Azure resource and deliver it to the attacker. That path is the only case in which impact extends beyond Snowflake; it is bounded by the token lifetime and the managed identity’s permissions. Successful exploitation requires WORKLOAD_IDENTITY authentication on a workload that already has an ambient cloud identity. Patched driver versions restrict this authenticator to recognized Snowflake hosts. Users must manually upgrade. |
| When a Quarkus application has multiple endpoints secured by individual OIDC provider tenants, such as "/oidc-provider1" that is secured by the OIDC Provider 1 and "/oidc-provider2" that is secured by the OIDC Provider 2, and an optional token introspection cache is also enabled, then a valid token issued by the OIDC Provider 1 that can be used to access "/oidc-provider1" can also be used to access "/oidc-provider2" that is secured by another OIDC Provider 2. |
| Insufficiently protected credentials in Microsoft Office allows an unauthorized attacker to perform spoofing over a network. |
| A security bypass vulnerability in the Account Protection feature of Palo Alto Networks Prisma® Browser enables a user to bypass intended security controls. |
| An information disclosure vulnerability in the Account Protection feature of Palo Alto Networks Prisma® Browser enables a local attacker to view sensitive data. |
| Insufficiently protected credentials in Azure CycleCloud allows an authorized attacker to disclose information over a network. |
| @sap/cds-mtxs NPM library does not perform sufficient checks on certain functionality used in multitenant CAP applications with extensibility enabled. An unauthenticated attacker could send specially crafted requests to obtain sensitive credentials and abuse them to replace or delete tenant data. Successful exploitation can result in a high impact on availability and integrity of the application. There may also be partial impact to the confidentiality of business data. |
| NetBox through 4.7.0 fails to redact sensitive data source backend credentials in REST and GraphQL API responses. Authenticated users with only view permission can retrieve plaintext passwords and secret keys for Git and Amazon S3 backends through API endpoints, gaining unauthorized access to external repositories and storage buckets. |
| nebula-mesh is a self-hosted control plane for Slack Nebula mesh VPN. Prior to version 0.3.8, Operator session tokens are stored in plaintext in the operator_sessions table (the token column is the PRIMARY KEY). The session token is a 32-byte random hex value sent directly in a cookie and valid for 24 hours. Anyone who can read the database (backup, snapshot, file copy, or SQL-level disclosure) obtains every active session token and can hijack operator sessions directly, with no further authentication. This issue has been patched in version 0.3.8. |
| Use of Cache Containing Sensitive Information vulnerability in ash-project ash_authentication_oauth2_server allows a shared HTTP cache to serve one tenant's OAuth discovery metadata to another tenant's clients.
The RFC 8414 and RFC 9728 metadata endpoints in AshAuthentication.Phoenix.Oauth2Server.ProtocolRouter return tenant-specific values (issuer, authorization_endpoint, token_endpoint, jwks_uri) when a tenant is set, but sent them with Cache-Control: public, max-age=3600 and no Vary. When the tenant is derived from something other than the URL (a header or the Host) and a shared cache sits in front, the cache key is the URL alone, so a stored response for one tenant is served to another for up to an hour. Affected clients may then send authorization codes and secrets to the wrong tenant's token endpoint and validate tokens against the wrong keys.
This issue affects ash_authentication_oauth2_server: from 0.1.3 before 0.3.1. |
