| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The GEO my WP plugin for WordPress is vulnerable to Local File Inclusion in all versions up to, and including, 4.5.5.3 via the gmw_posts_locator_ajax_info_window_loader function. This makes it possible for unauthenticated attackers to include and execute arbitrary .php files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where .php file types can be uploaded and included. In environments where PEAR is installed with register_argc_argv enabled, this file inclusion can be leveraged to write and execute arbitrary PHP code, achieving full remote code execution. |
| 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
The DRPC server kept a map from function name to request queue and created an entry the first time a
function name was seen. No code path ever removed an entry: request cleanup removed the request from its
queue, and the shutdown path drained queues, but the queue object and its map entry remained for the life of
the process.
Function names come from the client and are not constrained to functions any topology has registered, so the
number of retained entries is bounded only by the number of distinct names an attacker chooses to send, and
each retained entry holds the name itself. `drpc.authorizer` is unset by default, so no credentials are
required to reach the endpoint.
The retained state is permanent rather than a transient load spike, so the effect accumulates until the DRPC
server exhausts its heap.
Mitigation
Upgrade to 3.1.0, where a function's queue is removed once nothing is waiting in it.
Users who cannot upgrade immediately should configure `drpc.authorizer` so that only trusted principals can
reach the DRPC endpoints, and should ensure the DRPC ports are not reachable from untrusted networks.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| Description
Three separate mechanisms allowed a web page on an unrelated origin to read responses that Storm's HTTP
components served to an authenticated user.
The Logviewer reflected the request's `Origin` header back in `Access-Control-Allow-Origin` while also
sending `Access-Control-Allow-Credentials: true`. The published security model documents a permissive
`Access-Control-Allow-Origin: *` posture as accepted, which is safe precisely because browsers refuse to
honour `*` together with credentials; reflecting the concrete origin removes that protection.
The shared CORS filter used by the UI, the Logviewer and DRPC was configured with a response header name
where an initialisation parameter name was expected. The container ignored the setting and applied its own
defaults, which allow credentials.
Finally, the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET
request. A script element on any origin can load such a response, which bypasses the same-origin policy
entirely rather than negotiating it, and there was no way to turn the behaviour off.
In each case the effect is that a page visited by an authenticated operator can read cluster, topology and
log data on their behalf.
Mitigation
Upgrade to 3.1.0, where the Logviewer no longer reflects the request origin in a credentialed response, the
CORS filter is configured explicitly, and JSONP wrapping is governed by `ui.enable.jsonp`, which defaults to
false.
Note that disabling JSONP is a behaviour change for tooling that passes a `callback` query parameter; such
tooling should be moved to ordinary JSON requests.
Users who cannot upgrade immediately should place the UI, Logviewer and DRPC HTTP endpoints behind a reverse
proxy that strips `Access-Control-Allow-Origin` and `Access-Control-Allow-Credentials` from responses and
rejects requests carrying a `callback` parameter.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| 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
The worker's Netty message decoder is installed ahead of the SASL authentication handlers in the pipeline
and acts on frames before any authentication has taken place. It allocated buffers sized from a
length field carried in the frame, so a single frame from an unauthenticated peer able to reach a worker
slot port could drive a large allocation.
`storm.messaging.netty.authentication` defaults to false, and the decoder runs before the handler that
enforces it in any case, so no credentials are required. The attacker needs only TCP reachability to a
worker port.
The effect of a single frame at the default 768 MB worker heap has not been measured to distinguish
sustained worker loss from transient garbage-collection pressure. The severity assigned to this advisory
reflects the more conservative reading; consumers who require a precise figure should test against their own
worker heap configuration.
Mitigation
Upgrade to 3.1.0, where frames are decoded only after the handshake completes.
Users who cannot upgrade immediately should ensure that worker slot ports are reachable only from within the
cluster, as the security model already recommends, and should enable
`storm.messaging.netty.authentication` where the deployment permits it.
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
When launching a Docker or OCI worker, the setuid-root `worker-launcher` first changes ownership of the
entire worker directory to the untrusted topology user, and only afterwards reads and acts on the command
file that the supervisor wrote into that same directory. The file is opened without `O_NOFOLLOW` and without
re-verifying its owner, so between the ownership change and the read the tenant can replace its contents.
For the Docker path the parsed command is executed with real uid 0, and the command sanitiser is not a
privilege boundary: it admits `-v` with an arbitrary source, `--device`, `--cap-add`, `--security-opt`,
`--user` and `--net`, and copies positional arguments through verbatim. A rewritten file therefore yields an
attacker-authored, root-equivalent container invocation with the host filesystem available.
For the OCI path the same rewrite window applies, and mount validation is structural only, with no
source or destination allow-list, so arbitrary host paths can be bind-mounted read-write into the
container. The `username` field of the command file is likewise attacker-settable and is checked only
against non-root and minimum-uid rules, permitting execution as another tenant's uid.
Mitigation
Upgrade to 3.1.0, where the command file is validated before the ownership change and re-verified on open,
and where mount sources and destinations are constrained by configuration.
Users who cannot upgrade immediately should disable Docker and OCI worker isolation, or restrict topology
submission on affected supervisors to trusted principals. Note that the launcher must be rebuilt and
reinstalled after upgrading.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| Description
The setuid-root `worker-launcher` binary adjusts ownership and permissions of worker directories by walking
the tree with FTS and calling `lchown` and `chmod` on each entry's full pathname while running with an
effective uid of 0. Both syscalls re-resolve the path at the time of the call, after FTS has classified the
entry, and the trees being walked are owned and writable by the untrusted topology user.
A tenant running code on a supervisor node could therefore replace an intermediate directory component with
a symbolic link between classification and the privileged operation, redirecting the root-owned `lchown` or
`chmod` at an arbitrary file on the host. The operation is repeatable at will, since crashing a worker
forces a relaunch and blob updates re-run the walk, so a failed attempt costs the attacker nothing.
This crosses the boundary that `supervisor.run.worker.as.user` and container isolation are intended to
enforce. It is the same defect class as the Hadoop container-executor issues from which this code derives.
Mitigation
Upgrade to 3.1.0, where the privileged walk operates on file descriptors it has already stat'd rather than
on pathnames re-resolved at call time.
Users who cannot upgrade immediately should not run untrusted topology code on supervisors configured with
`supervisor.run.worker.as.user`, since the launcher is the boundary being crossed. Note that the launcher
must be rebuilt and reinstalled after upgrading; replacing the Java artifacts alone is not sufficient.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| Description
Dependency artifacts uploaded with `storm jar --artifacts` were stored under a blob key derived only from
the Maven coordinate, for example `dep---.jar`. The key was therefore identical
for every user of the cluster and predictable in advance. When the blob already existed, the uploader
caught `KeyAlreadyExistsException` and silently reused it, with no check that the existing blob's content
or owner matched the artifact the submitter had resolved.
A user who uploaded a blob under such a key first therefore controlled the bytes that every later submitter
of the same coordinate would receive on the worker classpath, resulting in code execution inside another
tenant's topology.
This affects deployments where more than one principal may create blobs and where the `--artifacts`
dependency feature is used.
Mitigation
Upgrade to 3.1.0, where each uploaded artifact receives a key carrying a freshly generated UUID and a
pre-existing blob is no longer silently reused.
Note that the corrected key generation is on the SUBMITTING CLIENT, so upgrading the cluster alone does not
close this; every client that runs `storm jar --artifacts` must also be upgraded. Operators should audit
existing `dep-` blobs for unexpected owners before upgrading. Users who cannot upgrade immediately should
avoid the `--artifacts` mechanism in multi-tenant clusters and distribute dependencies inside the topology
jar instead.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| Ekia File Manager 1.2.7 exposes com.ekia.filecontrolmanager.OpenFileProvider as an exported Android ContentProvider without requiring caller permissions.
The provider maps the caller-controlled URI path directly to a filesystem path and passes it to new File(...). It then supports query(), openFile(), and delete() operations. Because the provider is exported and lacks android:permission, android:readPermission, or android:writePermission, another local application can access the provider authority and cause File Manager's process to read, create, overwrite, or delete files that are accessible to that process. |
| Alior Bank PrestaShop module "raty" for commercial partners is vulnerable to SQL Injection in the "hookActionObjectProductUpdateBefore", "hookActionObjectCategoryUpdateBefore", and "hookActionObjectCategoryAddAfter" hook methods. The module inserts values of the POST parameters "alior_product_promotion", "alior_category_promotion" and "alior_category_enabled" directly into SQL UPDATE queries without any sanitization or validation. An attacker with access to the product or category add/edit functionality in the PrestaShop backoffice can inject arbitrary SQL, potentially allowing unauthorized access to and modification of database contents. This issue was fixed in versions: 9.0.7 and 8.1.11 |
| Incorrect privilege assignment vulnerability in Apache Syncope.
When the configured JWKS settings for internal JWT authentication are disclosed (at least protocol and key), an attacker can obtain admin privileges after completing a successful authentication and obtaining a valid low-privileges JWT.
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. |
| The The Events Calendar plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 6.17.4 via the is_safe_widget_instance function. This is due to insufficient protection in is_safe_widget_instance, which can be bypassed because PHP fires magic methods during its pre-parse, combined with enable_rendering_widget_copied() forging a valid wp_hash integrity attribute before unserialize() is reached. This makes it possible for unauthenticated attackers to execute code on the server. This is exploitable without authentication or approval because the plugin's V2 single-event template runs do_blocks() over buffered comment HTML, and WordPress returns a moderation-hash URL that allows an unauthenticated commenter to immediately view their own pending comment, delivering the injected block markup to the vulnerable code path before any moderation occurs. This does require comments to be enabled and visible on events. |
| 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. |
| The Smart Marketing SMS and Newsletters Forms plugin for WordPress is vulnerable to generic SQL Injection via Parameter Name in all versions up to, and including, 5.1.24 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with subscriber-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. Exploitation requires the plugin's sync feature to be enabled (options['enabled']) and get_option('egoi_mapping') to be truthy, both of which reflect ordinary configured states for the plugin's core contact mapping functionality. |
| Missing Authorization vulnerability in Apache Syncope.
An administrator with task execution entitlements might be able to mass (de)provision group members, regardless of their group-related administration capabilities.
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. |
| blaze is a Scala library for building asynchronous pipelines, with a focus on network IO. Prior to 0.23.18 and from 1.0.0-M1 until 1.0.0-M42, five HTTP/1.1 conformance laxities in the hand-written Java parser under http/src/main/java/org/http4s/blaze/http/parser/ can cause blaze to derive a different request boundary than a stricter fronting intermediary. A default BlazeServerBuilder accepts invalid or valueless header field names that violate tchar syntax, obsolete folded field lines (obs-fold), unsupported Transfer-Encoding values, duplicate Content-Length fields, and requests containing both Transfer-Encoding and Content-Length. If a lenient or legacy proxy forwards the malformed bytes but interprets them differently, the disagreement can permit front-end authorization bypass, response-queue poisoning on pooled backend connections, or cache poisoning. Exploitation requires a pair of disagreeing parsers; no non-default blaze configuration is required. The affected checks are enforced in BodyAndHeaderParser and Http1ServerParser. This issue is fixed in versions 0.23.18 and 1.0.0-M42. |
