CVE-2025-54798

What it actually does

The flaw is a path/symlink handling issue in tmp@0.2.3 as used by oakserver/oak. When code creates a temporary file or directory using an attacker-influenced dir parameter, the library may follow a symbolic link instead of safely constraining writes to an intended temporary location. This can allow an attacker who can control the temporary directory path or pre-place a symlink in a writable location to cause the application to create or overwrite files/directories at unintended filesystem paths with the privileges of the running process. Impact is generally limited by application-specific exposure, filesystem permissions, and whether untrusted input can reach the dir option.

Why it matters to the business

Successful exploitation could let an attacker tamper with files used by an affected application, potentially causing application errors, data corruption, or limited privilege escalation if sensitive writable paths are reachable by the application process. The assigned CVSS and EPSS are low, there is no known KEV listing, no ransomware association, and no reported exploit maturity, so this is not currently a broad internet exploitation priority; however, it should still be remediated in normal dependency maintenance because temporary-file vulnerabilities can become more serious in applications that process untrusted uploads, archives, build artifacts, or plugin-controlled paths.

How an attack unfolds

An attacker first needs a way to influence the directory path used for temporary file or directory creation, or a way to prepare a symlink in a location that the vulnerable application later uses for temporary operations. The attacker points the temporary directory parameter at a symbolic link or symlink-containing path that resolves outside the intended temporary area. When the vulnerable tmp@0.2.3 code creates a file or directory, it follows the symlink and writes to the attacker-selected destination instead of a safe temporary location. The practical outcome depends on what the application writes, whether existing files can be overwritten, and the privileges of the process. In a typical web-service context this may lead to file tampering or denial of service; in a privileged service or build pipeline it could potentially be chained with other weaknesses to modify configuration, scripts, cache files, or application-controlled artifacts.

How to fix it

Upgrade oakserver/oak to a revision that includes the fix, specifically commit b60e60330ef227707c4dc13ef0ea36192d894f44 or a later released version containing that commit. Ensure dependency lockfiles no longer resolve tmp to version 0.2.3 where the vulnerable behavior is reachable. If immediate upgrade is not possible, avoid passing attacker-controlled values to temporary-file dir options, force temporary files into a trusted directory owned by the application, reject paths containing symlinks, use lstat/realpath checks before writes, run the service with least-privilege filesystem permissions, and isolate temporary directories per process or workload with restrictive permissions.

How to confirm the fix worked

Confirm the deployed oakserver/oak version or source revision includes commit b60e60330ef227707c4dc13ef0ea36192d894f44 or later. Review package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, deno.lock, vendored dependency manifests, and SBOM output for tmp@0.2.3. Rebuild and redeploy from a clean dependency cache after upgrading. As a functional validation, test any code paths that create temporary files using configurable directories and verify symlinked temporary paths are rejected or resolved only within the intended trusted temporary directory. Confirm runtime service accounts cannot write to sensitive application, system, or configuration paths that are not required for normal operation.

Typical attack path

1. Identify an application or workflow using the vulnerable tmp@0.2.3 dependency through oakserver/oak or a downstream package.
2. Find an input, plugin, upload, archive extraction, build step, or API path that influences the temporary directory used by the application.
3. Create or reference a symbolic link that points from an allowed temporary location to a target path outside the intended directory.
4. Trigger the temporary file or directory creation operation in the vulnerable code path.
5. Cause the application process to write to the symlink target with its filesystem permissions.
6. Use the resulting file write for tampering, disruption, or as part of a chain to gain additional impact.

How to detect it

Look for evidence of unusual symlink use and unexpected file creation around application temporary-file operations. Useful sources include application logs, web/API request logs for parameters that control upload or temporary directories, file integrity monitoring alerts, endpoint telemetry for symlink creation and file writes, container runtime audit logs, CI/build logs, and Linux auditd or EDR filesystem events. Investigate writes by the affected application process to paths outside its expected temporary directory, especially shortly after requests, uploads, archive processing, plugin execution, or build jobs. Search for symlinks inside application-controlled temporary directories that point to application configuration, source directories, startup scripts, credential files, cache directories, or other sensitive locations. Also review dependency and deployment records to identify systems that ran tmp@0.2.3 while exposed to untrusted temporary-directory input. There are no public exploit-specific payload strings or actor-specific indicators known from the provided intelligence.

What your security team should do

• Inventory applications and build workflows that use oakserver/oak from Git or that bundle tmp@0.2.3.
• Prioritize remediation where untrusted users, uploaded content, plugins, CI jobs, or external requests can influence temporary-file locations.
• Upgrade to oakserver/oak commit b60e60330ef227707c4dc13ef0ea36192d894f44 or later and regenerate dependency lockfiles.
• Add dependency scanning rules to flag tmp@0.2.3 and affected oakserver/oak revisions in source repositories and container images.
• Harden runtime permissions so application processes cannot write to source code, startup scripts, service configuration, credential stores, or other high-impact filesystem locations.
• Review temporary-file handling patterns for use of attacker-controlled dir parameters and add canonical path and symlink checks where applicable.
• Because EPSS is low and there is no KEV or known ransomware use, handle through standard patch management unless the affected code path is externally reachable or runs with elevated privileges.