| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Allure 2 is the version 2.x branch of Allure Report, a multi-language test reporting tool. Prior to 2.39.0, the HTTP server started by allure serve and allure open uses URI.getPath() in Commands.setUpServer() in allure-commandline/src/main/java/io/qameta/allure/Commands.java and passes the percent-decoded request path to reportDirectory.resolve() without normalizing the result or confirming that it remains inside that directory. An unauthenticated client that can reach the server can submit parent-directory segments, including percent-encoded segments, and cause serveFile() to return any regular file readable by the Allure process. The server binds to localhost by default, but the --host option can expose it to other systems, and local users, adjacent containers, or browser-origin attacks may reach a local listener. This can disclose credentials, configuration, source code, build secrets, and other CI/CD data. This issue is fixed in version 2.39.0. |
| MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the confluence_upload_attachment and confluence_upload_attachments tools pass a client-controlled file_path through src/mcp_atlassian/confluence/attachments.py upload_attachment, and the jira_update_issue attachments parameter reaches src/mcp_atlassian/jira/attachments.py upload_attachment, without confining either path to an approved server workspace. In a remote HTTP, SSE, or multi-user deployment, absolute or traversing paths are resolved on the MCP server and uploaded to Atlassian, allowing a client with write-tool access to disclose server files, environment-held Atlassian credentials, or another tenant's data. A local single-user stdio deployment does not cross this trust boundary because the server runs in the caller's environment. This issue is fixed in version 0.22.0. |
| backpack/crud provides Create, Read, Update & Delete (CRUD) functions for Backpack, a collection of Laravel packages that help users build custom administration panels. Prior to 6.8.12 and 7.0.35, HasUploadFields::uploadMultipleFilesToDisk in src/app/Models/Traits/HasUploadFields.php trusts disk-relative paths from clear_<attribute>[] and passes them to Storage::disk()->delete without confirming that the paths are persisted on the current model record. An authenticated user with Update access to a CRUD using this mutator through src/app/Models/Traits/CrudTrait.php can delete another record's attachment, a shared asset, or another operational file on the configured disk by submitting its path. The newer MultipleFiles uploader is not affected because it intersects requested deletions with the record's persisted file list. This flaw does not permit reading the deleted files. The 5.x line remains affected through its final releases. This issue is fixed in versions 6.8.12 and 7.0.35. |
| Joomla Extension - joomshaper.com - Missing Directory Confinement in Media Rename Allowing Arbitrary File Rename in SP Page Builder (Free and Pro) 4.0.0 - 6.9.0 - The media rename task applied neither of the directory boundary checks used by the folder operations in the same controller, and its validation guard required only that either a media record exist for the supplied identifier or that the supplied path be present in #__spmedia, rather than both. The identifier and the path were consequently never checked against one another, so any valid media identifier could be paired with an unrelated filesystem path, and the STR input filter left traversal sequences intact. An attacker could rename files elsewhere in the installation, including renaming configuration.php to take the site offline. |
| knowns versions before 0.30.0 contain a path traversal vulnerability in the POST /api/templates/preview endpoint that allows unauthenticated attackers to read arbitrary files. Attackers can supply directory traversal sequences in the templateFile parameter to bypass path restrictions and read sensitive files like credentials and configuration through the JSON response. |
| excel-mcp-server 0.1.8 fails to enforce path confinement in stdio mode when EXCEL_FILES_PATH is unset, allowing attackers to read and write arbitrary files. Attackers can supply unchecked file paths to read and write tools to access any file accessible to the process. |
| firecrawl-mcp-server 3.20.2 contains an arbitrary local file read vulnerability in the firecrawl_parse tool that accepts unconstrained filePath arguments without directory containment validation. Attackers can supply absolute paths or directory traversal sequences to read sensitive files like credentials and environment variables, which are then uploaded and returned to the model context. |
| 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. |
| 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. |
| 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. |
| Anyquery is an SQL query engine built on top of SQLite. Prior to 0.4.5, the clear_plugin_cache(plugin) SQL scalar function in namespace/other_functions.go passes the caller-controlled plugin parameter through path.Join to os.RemoveAll without rejecting traversal segments. A low-privileged bearer-token holder can invoke the function through the /v1/query HTTP endpoint, causing path.Join to resolve .. segments outside $XDG_CACHE_HOME/anyquery/plugins/ and os.RemoveAll to recursively delete any reachable directory writable by the Anyquery server process. This causes permanent data loss and denial of service without disclosing file contents. This issue is fixed in version 0.4.5. |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to place files into the file system with Navigator for i when they should be blocked by Navigator configuration. This could allow attackers to upload files onto the system to places the Navigator support did not intend, but only if the profile could already do that by itself. |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 IBM DataStage could allow a remote authenticated attacker to read, write, or delete arbitrary files due to a path traversal vulnerability. |
| IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote authenticated attacker to execute arbitrary code due to improper limitation of a pathname to a restricted directory. |
| IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.5 could allow an authenticated user to send a specially crafted request to write arbitrary files on the system. |
| PyMuPDF through 1.28.2, fixed in commit b2c8f3a, contains a path traversal vulnerability in the font branch of extract_objects() in src/__main__.py, where the output filename is constructed by joining a document-controlled BaseFont name directly onto the user-supplied output directory without stripping path separators or dot-dot sequences. Attackers can supply a crafted PDF, EPUB, XPS, or FB2 file with a BaseFont name containing encoded path separators that decode to ../ sequences or absolute paths, causing arbitrary file writes outside the intended output directory without requiring authentication or elevated privileges. |
| Meshery before 1.0.57 contains an unauthenticated arbitrary file read vulnerability in the /api/system/fileView and /api/system/fileDownload endpoints that pass user-supplied file parameters directly to os.Open without path validation. Attackers can supply absolute paths or traversal sequences in the file parameter to read arbitrary files from the host filesystem without authentication. |
| next-video is a library for adding video to Next.js applications. Prior to 2.8.1, the GET endpoint exported by next-video/request-handler and commonly mounted at /api/video accepts an unauthenticated url query parameter, while src/utils/utils.ts isRemote() treats any value without an HTTP or HTTPS prefix as a local path. src/request-handler.ts passes that value through src/assets.ts getAssetPath() to src/config.ts loadAsset(), which appends a JSON suffix and uses fs.readFile without canonicalizing the path or verifying that it remains inside the configured video folder. A remote attacker can therefore escape the intended asset directory and read JSON files accessible to the application process, including Next.js server-action encryption material, preview-mode keys, build manifests, route metadata, absolute paths, and application video asset identifiers. Applications that do not expose the runtime request handler are not affected through this route. This issue is fixed in version 2.8.1. |
| OpenTelemetry, also known as OTel, is a vendor-neutral open source Observability framework for instrumenting, generating, collecting, and exporting telemetry data such as traces, metrics, and logs. Prior to 0.154.0, the Sentry exporter reads the remote OTLP sender-controlled service.name resource attribute in exporter/sentryexporter/sentry_exporter.go through extractProjectSlug and getOrCreateProjectEndpoint, passes the raw project slug to GetOTLPEndpoints and GetProjectKeys in exporter/sentryexporter/sentry_client.go, and interpolates it into a Sentry API URL without applying projectSlugRegexp through validateRoutingConfig at runtime in exporter/sentryexporter/config.go. Special characters can turn the expected path suffix into query data in all deployments or introduce slash and dot segments that traverse paths when the Sentry deployment normalizes them, while the Collector attaches its operator-configured bearer token to the request. A successful request can reach token-authorized administrative, organization, member, or key endpoints within the configured Sentry organization, and an attacker-controlled project slug can redirect subsequently exported telemetry. Sentry token middleware prevents cross-organization access. This issue is fixed in version 0.154.0. |
| A security vulnerability has been detected in 0x4m4 HexStrike AI up to d689933ff579d839c676c82b231f8e98326c5f04. The impacted element is the function FileOperationsManager of the file hexstrike_server.py of the component API Files Endpoint. The manipulation of the argument filename leads to path traversal. The attack may be initiated remotely. The exploit has been disclosed publicly and may be used. The project was informed of the problem early through an issue report but has not responded yet. |
