| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Out-of-bounds Read, Improper Input Validation vulnerability in Apache IoTDB C++ client.
Out-of-bounds reads in IoTDB C++ client TsBlock deserializer crash client
process on malformed server data.
This issue affects Apache IoTDB C++ client: from 1.3.5 before 1.3.8, from 2.0.5 before 2.0.10.
Users are recommended to upgrade to version 2.0.10, which fixes the issue. |
| Authentication bypass by spoofing vulnerability in Apache Syncope.
When the configured JWKS settings for internal JWT authentication are disclosed (at least protocol and key), an attacker can spoof another user's privileges after completing a successful authentication and obtaining a valid 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. |
| Description
A submitted topology carries two lists of blobstore keys, `dependency_jars` and `dependency_artifacts`,
which the client fills in after uploading the corresponding blobs. Nimbus performed no validation of their
contents on the submission path, yet acts on them in two places.
During cleanup of a finished topology, Nimbus deletes the keys named in those lists, and the deletion is
performed as the Nimbus subject, for which the blobstore short-circuits its ACL check. A submitter who
listed a key belonging to another topology, such as its `-stormjar.jar`, could therefore cause
that blob to be deleted when their own topology was cleaned up.
Separately, on acquiring leadership a Nimbus compares the dependency keys of all active topologies against
the blobstore contents and surrenders leadership if any is missing. A single key that does not exist, on a
single active topology, therefore causes every Nimbus to acquire leadership, surrender it and requeue
indefinitely, leaving the cluster without a leader and unable to schedule, clean up or accept submissions.
Mitigation
Upgrade to 3.1.0, where a submission is refused unless every entry in both lists is a dependency blob key
and exists in the blobstore.
Note that this validates new submissions only; a topology stored by an affected version with an invalid list
is unaffected by the upgrade. An operator whose cluster is failing to retain a leader should inspect the
Nimbus log for the dependency keys reported as missing and remove or resubmit the topology naming them.
Users who cannot upgrade immediately should restrict topology submission to trusted principals.
Credit
This issue was discovered by rzo1 while investigating an unrelated blobstore defect. |
| 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
Nimbus validated `topology.blobstore.map` against the calling subject at submission time only. The rebalance
operation accepts configuration overrides and stripped a small set of keys from them, but never re-ran that
validation, so a caller authorised to rebalance a topology could introduce a blobstore map entry naming a
blob whose ACL does not grant them access. Supervisors localise whatever key the map names, placing the
blob's contents into the topology's working directory.
The same advisory covers `listBlobs`, which performed no authorization check and passed no subject, unlike
the neighbouring `getBlobMeta` and `beginBlobDownload` operations. It therefore returned every key in the
blobstore to any caller able to reach the Nimbus Thrift port, which provides the key names that make the
above practical. On its own the disclosure is metadata only.
Mitigation
Upgrade to 3.1.0, where rebalance configuration overrides are validated exactly as submission-time
configuration is, against the rebalancing caller, and where `listBlobs` applies the configured
authorization.
Users who cannot upgrade immediately should restrict rebalance rights to trusted principals, keeping in mind
that membership of a topology's `topology.users` or `topology.groups` confers them.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| Description
`SimpleACLAuthorizer` evaluated the user-level command set by returning early when `nimbus.users` was empty,
before `nimbus.groups` was considered. An operator who restricted cluster access by group alone, leaving
`nimbus.users` unset, therefore received no restriction at all: every authenticated principal was permitted
every user-level operation, including `submitTopology`, `beginFileUpload` and `getNimbusConf`.
`docs/SECURITY.md` presents `nimbus.groups` as a supported way to lock down a cluster, so a deployment
following the documentation could believe it was restricted while it was not. The failure is silent; nothing
in the logs or the configuration indicates that the group list is being ignored.
Both lists left empty continues to mean that no restriction is configured, which is the shipped default and
is unchanged.
Mitigation
Upgrade to 3.1.0, where `nimbus.groups` is evaluated whether or not `nimbus.users` is set.
Users who cannot upgrade immediately should additionally populate `nimbus.users` with the intended
principals, since a non-empty user list causes the group list to be evaluated on affected versions.
Operators should review Nimbus access logs for operations by principals outside the intended groups.
Note that after upgrading, a cluster configured with `nimbus.groups` alone becomes restrictive for the first
time. This includes `NimbusClient`, which calls `getLeader` on every connection, so clients outside the
configured groups will begin to be refused.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| Description
A topology's `topology.blobstore.map` lets the submitter choose a local name for each blob that the
supervisor localises. That name was used to build a path under the topology's working directory without
normalisation, in both `AsyncLocalizer` and `Container.createBlobstoreLinks`, and the symlink helper
force-deletes whatever already exists at the target before creating the link.
A submitter could therefore use `../` segments to direct that delete-and-symlink operation at an arbitrary
path, as the supervisor user, on every node the topology is scheduled onto. The consequences include
recursive deletion of supervisor-owned content and planting a symlink that causes a subsequent worker
launch to execute attacker-chosen code as another tenant's operating-system user, which defeats the
isolation that `supervisor.run.worker.as.user` is intended to provide.
Mitigation
Upgrade to 3.1.0, where the resolved target must lie inside the expected root at both call sites.
Users who cannot upgrade immediately should restrict topology submission to trusted principals, and may
reject submissions whose `topology.blobstore.map` entries contain path separators or `..` segments before
they reach Nimbus.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| Authorization Bypass Through User-Controlled Key in the Order Manager component in Apache OFBiz 24.09.07 on all platforms allows an authenticated user with only view-level order permissions to modify or create OrderPaymentPreference records belonging to orders outside their authorized scope via the updateOrderPaymentPreference service, by supplying an orderPaymentPreferenceId belonging to a different order.
Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
| Authorization Bypass Through User-Controlled Key in Order Returns in Apache OFBiz 24.09 before 24.09.08 on all platforms allows an authenticated user with low-privileged Order Manager access to associate another party's OrderItem with a ReturnItem on a ReturnHeader they control, via the createReturnItem service. Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
| Direct Request ('Forced Browsing') to Financial Account services in Apache OFBiz 24.09 before 24.09.08 on all platforms allows an authenticated user with any valid low-privilege account to create, modify, and cancel financial account transactions and balances without appropriate permission via direct requests to the createFinAccount, updateFinAccount, deleteFinAccount, createFinAccountTrans, createFinAccountRole, createFinAccountAuth, setFinAccountTransStatus, and depositWithdrawPayments services.
Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
| Incorrect Implementation of Authentication Algorithm in the password-reset and login JWT validation in Apache OFBiz 24.09 before 24.09.08 on all platforms allows an attacker who has obtained a user's password-reset token (via email interception, log exposure, or a man-in-the-middle on the mail transport) to authenticate as that user and obtain a full, unrestricted session, including administrative access if the targeted account is an administrator, by submitting the token directly to the login endpoint instead of the intended password-change flow. Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in the Catalog image viewer in Apache OFBiz 24.09 before 24.09.08 on all platforms allows an unauthenticated attacker to execute arbitrary JavaScript in the browser session of a logged-in back-office user via a crafted viewImage URL that the user opens from within the application.
Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
| Incorrect Privilege Assignment in the Order Manager in Apache OFBiz 24.09 before 24.09.08 on all platforms allows an authenticated user who holds only order view permissions (ORDERMGR_VIEW), without ORDERMGR_UPDATE or any role on the order, to modify approved orders, changing a ship group's shipping address and shipment method or appending items with an overridden price, via the updateShipGroupShipInfo and appendOrderItem services. Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
| Direct Request ('Forced Browsing') in the Order component in Apache OFBiz 24.09 before 24.09.08 on all platforms allows an authenticated user with only view access to the Order Manager to modify the shipment tracking number of any order via a direct request to the updateTrackingNumber endpoint. Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
| Authorization Bypass Through User-Controlled Key in the shopping list services in Apache OFBiz 24.09 before 24.09.08 on all platforms allows an authenticated low-privileged user, such as a self-registered ecommerce customer, to modify another party's shopping list or take ownership of it, and thereby read its contents, via a request to the shopping list update endpoint that supplies the other party's shopping list ID.
Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
| Authorization Bypass Through User-Controlled Key in the content viewing component in Apache OFBiz 24.09 before 24.09.08 on all platforms allows an authenticated user with role-scoped content view permission to read the data of content they are not authorized to view via a ViewSimpleContent request that combines a contentId they can view with the dataResourceId of other content.
Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
| Authentication bypass by Assumed-Immutable data vulnerability in Apache OFBiz.
Apache OFBiz's optional Janrain Engage Social Login integration in the ecommerce component improperly binds authenticated external identities to local user accounts.
This issue affects Apache OFBiz: before 24.09.08.
Users are recommended to upgrade to version 24.09.08, which fixes the issue. |
| Server-Side Request Forgery in ViewDataFile in Apache OFBiz 24.09 before 24.09.08 on all platforms allows a remote authenticated attacker holding only the base webtools permissions (OFBTOOLS_VIEW, WEBTOOLS_VIEW) to cause the server to issue arbitrary outbound HTTP requests, and an attacker additionally holding ENTITY_MAINT and DATAFILE_MAINT to read arbitrary local files via a file: URL, by supplying the DEFINITION_LOCATION or DATAFILE_LOCATION request parameter to the viewdatafile screen, because ViewDataFile.groovy dereferences both parameters as java.net.URL objects with no scheme allow-list, host filter, or egress control inside a screen action that runs before the screen's and template's permission checks are evaluated, so the fetch executes regardless of whether the requesting account is authorized to view its result. Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
| Uncontrolled Resource Consumption in ServiceMultiEventHandler in Apache OFBiz 24.09 before 24.09.08 on all platforms allows a remote unauthenticated attacker to pin a server request thread for an attacker-chosen number of synchronous service dispatches, up to the signed-integer maximum, by submitting a single small HTTP request whose parameter names encode a row count via the "o" suffix used by multi-form submissions, because UtilHttp.getMultiFormRowCount derives that count from the largest such suffix with no upper bound and ServiceMultiEventHandler.invoke then loops that many times calling dispatcher.runSync, with the request-map for getFinAccountTransRunningTotalAndBalances reaching this handler with no authentication or CSRF requirement on a stock deployment. Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
| Authentication Bypass by Capture-replay in ExternalLoginKeysManager in Apache OFBiz 24.09 before 24.09.08 on all platforms allows a remote unauthenticated attacker who captures a live externalLoginKey value to obtain a complete, cookie-free, reusable session as the user who issued it, in every webapp that user can reach, because checkExternalLoginKey runs as a global preprocessor ahead of both the CSRF and authentication checks and accepts the key as a bearer credential that is never bound to a client, never expires, and is not invalidated after use, while the framework itself both appends live keys to every cross-webapp link it renders and, via WidgetWorker's unvalidated inter-app link target, lets an authenticated user's key be attached to an attacker-chosen absolute URL and delivered directly to the attacker's own server. Users are recommended to upgrade to version 24.09.08, which fixes this issue. |
