Vulnerabilidades de Apache Software Foundation

Description The Logviewer offers `logs.users` and `logs.groups` so operators can control who may read log content. For daemon logs those settings were not applied: the access decision combined the "this is a daemon log" flag with the authorizer result in a way that discarded the authorizer's answer whenever the flag was set, and the daemon log page and download endpoints reached the handler without consulting an authorizer at all. Any user able to pass the configured servlet filter could therefore read `nimbus.log`, `supervisor.log` and the other daemon logs on every reachable node, which contain other tenants' topology names, owners and configuration fragments. The same advisory covers the log listing endpoints, which accepted a user argument and never applied it, so `/listLogs` and `/searchLogs` returned every tenant's topology and worker log file names regardless of the caller. That part is metadata only. There was no configuration that closed either behaviour. Mitigation Upgrade to 3.1.0, where the daemon log paths evaluate the same configured user and group lists that the worker log paths already used, and the listing endpoints filter by the requesting user. Users who cannot upgrade immediately should place the Logviewer behind a reverse proxy that restricts the daemon log endpoints, and should treat daemon log content as readable by any filter-authenticated user. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

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.

Description Nimbus accepted the `uploadedJarLocation` argument of `submitTopology` / `submitTopologyWithOpts` as a server-side path and opened it directly, without checking that it referred to a file the caller had actually uploaded. The intended flow is that a client first calls `beginFileUpload`, which returns a path inside the Nimbus inbox, and uploads the jar in chunks to that location; nothing bound submission to that flow, and the `uploaders` map populated by `beginFileUpload` was never consulted at submit time. An authenticated user with topology submission rights could therefore submit any path readable by the Nimbus daemon user as their topology jar. Nimbus copied the file into the topology's jar blob, and the blob ACL grants the submitting subject read access, so the contents could then be retrieved with the ordinary blob download RPCs. Candidate targets include the Nimbus Kerberos keytab, Thrift and UI TLS private keys, and `storm.yaml` with the ZooKeeper authentication payload. Possession of the Nimbus keytab turns an ordinary tenant into a cluster administrator. In a deployment configured as the documentation recommends, submission is available to every authenticated principal when `nimbus.users` is unset, so no elevated privilege is required. Mitigation Upgrade to 3.1.0, where the submitted location is canonicalised and must resolve inside the Nimbus inbox. Users who cannot upgrade immediately should restrict topology submission to trusted principals via `nimbus.users` or `nimbus.groups`, and should treat any file readable by the Nimbus daemon user as potentially exposed to submitters: rotate the Nimbus keytab and any TLS private keys or ZooKeeper credentials reachable from that account. Local mode is unaffected. Credit Independently reported to the Apache Storm PMC by n0mi1k, with a proof of concept. Also found by the ASF using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

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.

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Apache Syncope. When the Syncope SRA is configured for CAS authentication, the target Apereo CAS instance's URL is calculated by unconditionally looking at client-supplied forwarded HTTP headers. 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.

Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Apache Syncope. The notification message, as optionally shown by Console's and Enduser's login pages can be instructed to display HTML tags with unsafe JS inline, via malicious HTTP link generation. This issue affects Apache Syncope: from 4.0.4 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.

Exposure of sensitive information through data queries vulnerability in Apache Syncope. An administrator with adequate entitlements for Derived Schemas can create a malicious JEXL expression which allows any administrator with sufficient entitlements for User read to access LinkedAccount's (if present) or Manager's (if defined) sensitive information, possibly including hashed credentials. 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.

Improper Control of Generation of Code ('Code Injection') vulnerability in Apache Syncope. An administrator with adequate entitlements for Implementations can create a malicious Groovy Command class containing untrusted code in their CommandArgs static implementation, bypassing the Groovy security sandbox. 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.