CWE-552
AllowedFiles or Directories Accessible to External Parties
Abstraction: Base · Status: Draft
The product makes files or directories accessible to unauthorized actors, even though they should not be.
714 vulnerabilities reference this CWE, most recent first.
GHSA-FX8P-8GCH-GJP7
Vulnerability from github – Published: 2022-01-11 00:00 – Updated: 2022-01-15 00:03Implicit Intent hijacking vulnerability in ActivityMetricsLogger prior to SMR Jan-2022 Release 1 allows attackers to get running application information.
{
"affected": [],
"aliases": [
"CVE-2022-22267"
],
"database_specific": {
"cwe_ids": [
"CWE-552"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-10T14:12:00Z",
"severity": "LOW"
},
"details": "Implicit Intent hijacking vulnerability in ActivityMetricsLogger prior to SMR Jan-2022 Release 1 allows attackers to get running application information.",
"id": "GHSA-fx8p-8gch-gjp7",
"modified": "2022-01-15T00:03:22Z",
"published": "2022-01-11T00:00:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22267"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FXC4-GGQH-5WG4
Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-08-06 00:00It has been discovered that redhat-certification does not restrict file access in the /update/results page. A remote attacker could use this vulnerability to remove any file accessible by the user which is running httpd. This flaw affects redhat-certification version 7.
{
"affected": [],
"aliases": [
"CVE-2018-10867"
],
"database_specific": {
"cwe_ids": [
"CWE-552"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-26T19:15:00Z",
"severity": "CRITICAL"
},
"details": "It has been discovered that redhat-certification does not restrict file access in the /update/results page. A remote attacker could use this vulnerability to remove any file accessible by the user which is running httpd. This flaw affects redhat-certification version 7.",
"id": "GHSA-fxc4-ggqh-5wg4",
"modified": "2022-08-06T00:00:44Z",
"published": "2022-05-24T19:03:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10867"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2018-10867"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1593764"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G29J-RWFV-H99W
Vulnerability from github – Published: 2026-09-02 22:12 – Updated: 2026-09-02 22:12Summary
com.github.jknack.handlebars.springmvc.SpringTemplateLoader resolves Spring MVC view names into URLs via Spring's ResourceLoader without applying the path-containment check that protects every other URL-based loader in the project (ClassPathTemplateLoader, FileTemplateLoader, ServletContextTemplateLoader - all hardened by commit d177cdee).
The only remaining defense for file: / classpath: view names is the unconditional .hbs suffix appended by AbstractTemplateLoader.resolve(...). This suffix is the load-bearing security boundary that prevents a request like view=file:/etc/passwd from reading /etc/passwd instead of /etc/passwd.hbs.
This boundary is bypassed by a single character: # (the URL fragment delimiter).
When the view name ends with #, the appended .hbs lands inside the URL fragment. Both Spring's FileUrlResource.exists() (via URI.getSchemeSpecificPart()) and the JDK's URL.openStream() (via URL.getFile()) silently discard the fragment, so the file actually opened is the bare path the attacker specified - for example /etc/passwd rather than /etc/passwd.hbs. The compiled "template" is then parsed and rendered into the HTTP response body.
Result: unauthenticated, network-reachable, arbitrary file read of any file readable by the JVM process on any Spring MVC application that uses a default-configured HandlebarsViewResolver and exposes a controller that returns a (fully or partly) user-influenced view name.
Vulnerable Code
SpringTemplateLoader.resolve - preserves file: / classpath: and applies suffix to the path portion
// handlebars-springmvc/.../SpringTemplateLoader.java:66-77
@Override
public String resolve(final String location) {
String protocol = null;
if (location.startsWith(ResourceUtils.CLASSPATH_URL_PREFIX)) {
protocol = ResourceUtils.CLASSPATH_URL_PREFIX;
} else if (location.startsWith(ResourceUtils.FILE_URL_PREFIX)) {
protocol = ResourceUtils.FILE_URL_PREFIX; // matches "file:"
}
if (protocol == null) {
return super.resolve(location);
}
return protocol + super.resolve(location.substring(protocol.length()));
}
SpringTemplateLoader.getResource - no containment check
// handlebars-springmvc/.../SpringTemplateLoader.java:57-63
@Override
protected URL getResource(final String location) throws IOException {
Resource resource = loader.getResource(location); // trust Spring blindly
if (!resource.exists()) {
return null;
}
return resource.getURL();
}
Contrast with the hardened sibling ClassPathTemplateLoader.getResource, which delegates to URLTemplateLoader.classpathResource(...) - the containment helper added by commit d177cdee:
// handlebars/.../io/URLTemplateLoader.java:75-93 (the d177cdee hardening)
protected final String classpathResource(String location) {
String resolvedPath =
Paths.get(location).normalize().toString().replace(java.io.File.separatorChar, '/');
if (location.startsWith("/") && !resolvedPath.startsWith("/")) {
resolvedPath = "/" + resolvedPath;
}
String prefix = getPrefix();
if (!prefix.equals("/") && !resolvedPath.startsWith(prefix)) {
throw new IllegalArgumentException(
"Path traversal attempt detected. Resolved path escapes base prefix: " + location);
}
return resolvedPath;
}
SpringTemplateLoader.getResource never calls this helper.
HandlebarsViewResolver - strips the outer prefix/suffix and forwards to compile, no validation
// handlebars-springmvc/.../HandlebarsViewResolver.java:112-117
public HandlebarsViewResolver(final Class<? extends HandlebarsView> viewClass) {
setViewClass(viewClass);
setContentType(DEFAULT_CONTENT_TYPE);
setPrefix(TemplateLoader.DEFAULT_PREFIX); // "/"
setSuffix(TemplateLoader.DEFAULT_SUFFIX); // ".hbs"
}
// handlebars-springmvc/.../HandlebarsViewResolver.java:163-178
protected AbstractUrlBasedView configure(final HandlebarsView view) throws IOException {
String url = view.getUrl();
url = url.substring(getPrefix().length(), url.length() - getSuffix().length());
try {
view.setTemplate(handlebars.compile(url)); // ← attacker-controlled url
view.setValueResolver(valueResolvers.toArray(new ValueResolver[0]));
} catch (IOException ex) {
if (failOnMissingFile) throw ex;
logger.debug("File not found: " + url);
}
return view;
}
AbstractTemplateLoader.resolve - the load-bearing .hbs gate
// handlebars/.../io/AbstractTemplateLoader.java:47-50
@Override
public String resolve(final String uri) {
return prefix + normalize(uri) + suffix; // "/" + path + ".hbs"
}
The suffix string is concatenated as a string. Whether that string lands in the path component, query component, or fragment component of the resulting URL is decided by Spring's URL parsing - not by Handlebars.
Impact
Direct primitive
Unauthenticated arbitrary file read of any file readable by the JVM process UID.
Real-world attack chains (downstream impact)
- Read
application.yml-> extractjwt.secret/spring.datasource.password-> forge admin JWT or directly connect to the database. Common Spring Boot deployment pattern; one request to game-over. - Read AWS / GCP credentials -> assume role -> exfiltrate buckets, modify infrastructure.
- Read K8s service-account token -> API-server access scoped to the pod's role -> namespace lateral movement, secret exfiltration.
- Read
/proc/self/environ-> harvest CI/CD-injected secrets that never appear on disk. - Read private keys (
id_rsa, TLS keys) -> impersonate host / decrypt MITM'd traffic / sign commits. - Read the application's source-code-on-disk to discover further server-side endpoints, hardcoded credentials, or chains.
Indirect
- Confirmed reachable from any controller that returns user-influenced view names - a documented Spring anti-pattern that nevertheless appears in production (CMS preview endpoints, theme switchers, multi-tenant view routing,
@RequestMapping("/{view}")patterns,DefaultRequestToViewNameTranslator-driven URL->view mappings). - No authentication, no privilege, no clicks - a single Internet HTTP GET.
Remediation
Any of the following independently closes the bypass. We recommend implementing #1 and #2 for defense in depth.
Apply the containment helper to SpringTemplateLoader.getResource (parity with d177cdee)
// handlebars-springmvc/.../SpringTemplateLoader.java
@Override
protected URL getResource(final String location) throws IOException {
// For classpath: locations, delegate to the hardened helper as ClassPathTemplateLoader does.
// For file: locations, perform an explicit canonical-path containment check.
Resource resource = loader.getResource(location);
if (!resource.exists()) {
return null;
}
URL url = resource.getURL();
validateNoUnsafeUrlComponents(url); // see 9.3
return url;
}
Validate the resolved URL components
private static void validateNoUnsafeUrlComponents(URL url) {
if (url.getRef() != null) {
throw new IllegalArgumentException(
"Template URL must not contain a fragment: " + url);
}
if (url.getQuery() != null) {
throw new IllegalArgumentException(
"Template URL must not contain a query: " + url);
}
}
This is the structural fix - it ensures the textual .hbs check matches the resolved-file behavior regardless of input shape.
Remove the protocol short-circuit entirely
If the supported deployment model is "templates live in one well-known prefix", SpringTemplateLoader.resolve should not preserve file: / classpath: prefixes from user input at all. Either remove that branch, or require an explicit allow-list in the constructor:
public SpringTemplateLoader(ResourceLoader loader, boolean allowProtocolPrefixes) { ... }
with the default being false.
Validate the stripped view name in HandlebarsViewResolver.configure
// handlebars-springmvc/.../HandlebarsViewResolver.java:163-178
protected AbstractUrlBasedView configure(final HandlebarsView view) throws IOException {
String url = view.getUrl();
url = url.substring(getPrefix().length(), url.length() - getSuffix().length());
if (url.contains(":") || url.contains("#") || url.contains("..")) {
throw new IllegalArgumentException("Unsafe view name: " + url);
}
// ...
}
This is a defense-in-depth check that rejects view names containing protocols, fragments, or traversal sequences. It does not by itself remove the SpringTemplateLoader weakness (developers calling handlebars.compile(...) directly still bypass it), but it eliminates the most common reach pattern.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.github.jknack:handlebars-springmvc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-63490"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-23",
"CWE-552"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-02T22:12:03Z",
"nvd_published_at": "2026-08-20T15:18:04Z",
"severity": "HIGH"
},
"details": "### Summary\n`com.github.jknack.handlebars.springmvc.SpringTemplateLoader` resolves Spring MVC view names into URLs via Spring\u0027s `ResourceLoader` **without applying the path-containment check** that protects every other URL-based loader in the project (`ClassPathTemplateLoader`, `FileTemplateLoader`, `ServletContextTemplateLoader` - all hardened by commit `d177cdee`).\n\nThe only remaining defense for `file:` / `classpath:` view names is the unconditional `.hbs` suffix appended by `AbstractTemplateLoader.resolve(...)`. This suffix is the load-bearing security boundary that prevents a request like `view=file:/etc/passwd` from reading `/etc/passwd` instead of `/etc/passwd.hbs`.\n\n**This boundary is bypassed by a single character: `#` (the URL fragment delimiter).**\n\nWhen the view name ends with `#`, the appended `.hbs` lands inside the URL fragment. Both Spring\u0027s `FileUrlResource.exists()` (via `URI.getSchemeSpecificPart()`) and the JDK\u0027s `URL.openStream()` (via `URL.getFile()`) **silently discard the fragment**, so the file actually opened is the bare path the attacker specified - for example `/etc/passwd` rather than `/etc/passwd.hbs`. The compiled \"template\" is then parsed and rendered into the HTTP response body.\n\nResult: **unauthenticated, network-reachable, arbitrary file read** of any file readable by the JVM process on any Spring MVC application that uses a default-configured `HandlebarsViewResolver` and exposes a controller that returns a (fully or partly) user-influenced view name.\n\n### Vulnerable Code\n\n#### `SpringTemplateLoader.resolve` - preserves `file:` / `classpath:` and applies suffix to the path portion\n\n```java\n// handlebars-springmvc/.../SpringTemplateLoader.java:66-77\n@Override\npublic String resolve(final String location) {\n String protocol = null;\n if (location.startsWith(ResourceUtils.CLASSPATH_URL_PREFIX)) {\n protocol = ResourceUtils.CLASSPATH_URL_PREFIX;\n } else if (location.startsWith(ResourceUtils.FILE_URL_PREFIX)) {\n protocol = ResourceUtils.FILE_URL_PREFIX; // matches \"file:\"\n }\n if (protocol == null) {\n return super.resolve(location);\n }\n return protocol + super.resolve(location.substring(protocol.length()));\n}\n```\n\n#### `SpringTemplateLoader.getResource` - **no containment check**\n\n```java\n// handlebars-springmvc/.../SpringTemplateLoader.java:57-63\n@Override\nprotected URL getResource(final String location) throws IOException {\n Resource resource = loader.getResource(location); // trust Spring blindly\n if (!resource.exists()) {\n return null;\n }\n return resource.getURL();\n}\n```\n\nContrast with the hardened sibling `ClassPathTemplateLoader.getResource`, which delegates to `URLTemplateLoader.classpathResource(...)` - the containment helper added by commit `d177cdee`:\n\n```java\n// handlebars/.../io/URLTemplateLoader.java:75-93 (the d177cdee hardening)\nprotected final String classpathResource(String location) {\n String resolvedPath =\n Paths.get(location).normalize().toString().replace(java.io.File.separatorChar, \u0027/\u0027);\n if (location.startsWith(\"/\") \u0026\u0026 !resolvedPath.startsWith(\"/\")) {\n resolvedPath = \"/\" + resolvedPath;\n }\n String prefix = getPrefix();\n if (!prefix.equals(\"/\") \u0026\u0026 !resolvedPath.startsWith(prefix)) {\n throw new IllegalArgumentException(\n \"Path traversal attempt detected. Resolved path escapes base prefix: \" + location);\n }\n return resolvedPath;\n}\n```\n\n`SpringTemplateLoader.getResource` never calls this helper.\n\n#### `HandlebarsViewResolver` - strips the outer prefix/suffix and forwards to compile, no validation\n\n```java\n// handlebars-springmvc/.../HandlebarsViewResolver.java:112-117\npublic HandlebarsViewResolver(final Class\u003c? extends HandlebarsView\u003e viewClass) {\n setViewClass(viewClass);\n setContentType(DEFAULT_CONTENT_TYPE);\n setPrefix(TemplateLoader.DEFAULT_PREFIX); // \"/\"\n setSuffix(TemplateLoader.DEFAULT_SUFFIX); // \".hbs\"\n}\n\n// handlebars-springmvc/.../HandlebarsViewResolver.java:163-178\nprotected AbstractUrlBasedView configure(final HandlebarsView view) throws IOException {\n String url = view.getUrl();\n url = url.substring(getPrefix().length(), url.length() - getSuffix().length());\n try {\n view.setTemplate(handlebars.compile(url)); // \u2190 attacker-controlled url\n view.setValueResolver(valueResolvers.toArray(new ValueResolver[0]));\n } catch (IOException ex) {\n if (failOnMissingFile) throw ex;\n logger.debug(\"File not found: \" + url);\n }\n return view;\n}\n```\n\n#### `AbstractTemplateLoader.resolve` - the load-bearing `.hbs` gate\n\n```java\n// handlebars/.../io/AbstractTemplateLoader.java:47-50\n@Override\npublic String resolve(final String uri) {\n return prefix + normalize(uri) + suffix; // \"/\" + path + \".hbs\"\n}\n```\n\nThe suffix string is concatenated as a string. Whether that string lands in the path component, query component, or fragment component of the resulting URL is decided by Spring\u0027s URL parsing - not by Handlebars.\n\n### Impact\n\n#### Direct primitive\n\nUnauthenticated arbitrary file read of any file readable by the JVM process UID.\n\n#### Real-world attack chains (downstream impact)\n\n1. **Read `application.yml` -\u003e extract `jwt.secret` / `spring.datasource.password` -\u003e forge admin JWT or directly connect to the database.** Common Spring Boot deployment pattern; one request to game-over.\n2. **Read AWS / GCP credentials -\u003e assume role -\u003e exfiltrate buckets, modify infrastructure.**\n3. **Read K8s service-account token -\u003e API-server access scoped to the pod\u0027s role -\u003e namespace lateral movement, secret exfiltration.**\n4. **Read `/proc/self/environ` -\u003e harvest CI/CD-injected secrets that never appear on disk.**\n5. **Read private keys (`id_rsa`, TLS keys) -\u003e impersonate host / decrypt MITM\u0027d traffic / sign commits.**\n6. **Read the application\u0027s source-code-on-disk** to discover further server-side endpoints, hardcoded credentials, or chains.\n\n#### Indirect\n\n* Confirmed reachable from any controller that returns user-influenced view names - a documented Spring anti-pattern that nevertheless appears in production (CMS preview endpoints, theme switchers, multi-tenant view routing, `@RequestMapping(\"/{view}\")` patterns, `DefaultRequestToViewNameTranslator`-driven URL-\u003eview mappings).\n* No authentication, no privilege, no clicks - a single Internet HTTP GET.\n\n### Remediation\n\nAny of the following independently closes the bypass. We recommend implementing **#1 and #2** for defense in depth.\n\n#### Apply the containment helper to `SpringTemplateLoader.getResource` (parity with d177cdee)\n\n```java\n// handlebars-springmvc/.../SpringTemplateLoader.java\n@Override\nprotected URL getResource(final String location) throws IOException {\n // For classpath: locations, delegate to the hardened helper as ClassPathTemplateLoader does.\n // For file: locations, perform an explicit canonical-path containment check.\n Resource resource = loader.getResource(location);\n if (!resource.exists()) {\n return null;\n }\n URL url = resource.getURL();\n validateNoUnsafeUrlComponents(url); // see 9.3\n return url;\n}\n```\n\n#### Validate the resolved URL components\n\n```java\nprivate static void validateNoUnsafeUrlComponents(URL url) {\n if (url.getRef() != null) {\n throw new IllegalArgumentException(\n \"Template URL must not contain a fragment: \" + url);\n }\n if (url.getQuery() != null) {\n throw new IllegalArgumentException(\n \"Template URL must not contain a query: \" + url);\n }\n}\n```\n\nThis is the **structural** fix - it ensures the textual `.hbs` check matches the resolved-file behavior regardless of input shape.\n\n#### Remove the protocol short-circuit entirely\n\nIf the supported deployment model is \"templates live in one well-known prefix\", `SpringTemplateLoader.resolve` should not preserve `file:` / `classpath:` prefixes from user input at all. Either remove that branch, or require an explicit allow-list in the constructor:\n\n```java\npublic SpringTemplateLoader(ResourceLoader loader, boolean allowProtocolPrefixes) { ... }\n```\n\nwith the default being `false`.\n\n#### Validate the stripped view name in `HandlebarsViewResolver.configure`\n\n```java\n// handlebars-springmvc/.../HandlebarsViewResolver.java:163-178\nprotected AbstractUrlBasedView configure(final HandlebarsView view) throws IOException {\n String url = view.getUrl();\n url = url.substring(getPrefix().length(), url.length() - getSuffix().length());\n if (url.contains(\":\") || url.contains(\"#\") || url.contains(\"..\")) {\n throw new IllegalArgumentException(\"Unsafe view name: \" + url);\n }\n // ...\n}\n```\n\nThis is a defense-in-depth check that rejects view names containing protocols, fragments, or traversal sequences. It does not by itself remove the SpringTemplateLoader weakness (developers calling `handlebars.compile(...)` directly still bypass it), but it eliminates the most common reach pattern.",
"id": "GHSA-g29j-rwfv-h99w",
"modified": "2026-09-02T22:12:03Z",
"published": "2026-09-02T22:12:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jknack/handlebars.java/security/advisories/GHSA-g29j-rwfv-h99w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63490"
},
{
"type": "WEB",
"url": "https://github.com/jknack/handlebars.java/commit/61f43423a337b87db5fec1fe59f0725aaaa38df5"
},
{
"type": "PACKAGE",
"url": "https://github.com/jknack/handlebars.java"
},
{
"type": "WEB",
"url": "https://github.com/jknack/handlebars.java/releases/tag/v4.5.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Handlebars.java: Arbitrary file read in `SpringTemplateLoader` via URL-fragment suffix bypass"
}
GHSA-G39V-CVJH-8FPF
Vulnerability from github – Published: 2026-05-14 20:17 – Updated: 2026-05-14 20:17Summary
When ENABLE_YAML_CONFIG_EDITING=true, every ha_config_set_yaml call backs up the pre-edit file to <config>/www/yaml_backups/, which Home Assistant serves at /local/ with no authentication. Anyone who can reach the HA web interface can download the most recent pre-edit configuration.yaml (or other YAML file) — typically containing plaintext MQTT passwords, REST credentials, webhook IDs, geofence coordinates, and shell_command definitions — with zero credentials.
Details
The backup feature is good — do_backup defaults to True and protects users from a bad edit. The issue is the location:
custom_components/ha_mcp_tools/__init__.py:596—backup_dir = config_dir / "www" / "yaml_backups"custom_components/ha_mcp_tools/__init__.py:602—backup_file = backup_dir / f"{safe_name}.{timestamp}.bak"custom_components/ha_mcp_tools/__init__.py:606-607,692-693— backup path returned to caller and logged at INFO
<config>/www/ is /local/ and HA serves it unauthenticated by design (intended for static dashboard assets). An attacker discovers the path three ways: (1) it's returned to the MCP client in result["backup_path"]; (2) it's logged at INFO and recoverable via ha_get_logs; (3) the timestamp format is %Y%m%d_%H%M%S — 86,400 candidates per day, enumerable. Backups accumulate (no rotation), so a long-running install holds a chronological history.
Preconditions: ENABLE_YAML_CONFIG_EDITING=true (off by default), at least one YAML edit made, and the attacker can reach HA's port 8123 (LAN, or internet via Nabu Casa / reverse proxy).
PoC
A pytest E2E test against a fresh Docker HA container with the custom component installed (using the project's existing ha_container_with_fresh_config fixture):
[1] ha_config_set_yaml(yaml_path="template", action="add", ...) → success=True
[1] backup_path = 'www/yaml_backups/configuration.yaml.20260505_171335.bak'
[2] GET http://<ha>:8123/local/yaml_backups/configuration.yaml.20260505_171335.bak
(no Authorization header)
[2] HTTP 200, 440 bytes — the full pre-edit configuration.yaml
[control] GET /api/config without auth → HTTP 401
The control proves the result is meaningful: the same instance returns 401 for an authenticated endpoint; only /local/ is unauthenticated by HA design.
Impact
CWE-552 (Files or Directories Accessible to External Parties). Affects users with ENABLE_YAML_CONFIG_EDITING=true who have made at least one YAML edit. Anyone who can reach HA port 8123 reads the most recent pre-edit config without credentials. CVSS 6.5 medium (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N); 7.5 high if HA is internet-exposed.
Resolution
Fixed in 7.4.1.dev456 (PR #1180). The fix relocates new backups to <config>/.ha_mcp_tools_backups/ (config root, not served by /local/) and adds a one-time migration on integration setup that moves any pre-existing exposed backups, surfaces a persistent notification telling the user to rotate exposed secrets, and removes the legacy directory if empty.
The fix ships in the next biweekly stable release and is available immediately on the dev channel. Updating to a release containing the fix is sufficient — no manual action required for users who upgrade.
Manual cleanup (for users who cannot upgrade yet)
If you used ha_config_set_yaml on a vulnerable version and cannot wait for the next stable release, manually remove the exposed backups:
rm -rf <config>/www/yaml_backups/
Then rotate any secrets that may have been in the YAML files those backups captured (MQTT/REST credentials, webhook IDs, shell_command definitions, geofence coordinates). The directory is reachable at http(s)://<ha-host>:8123/local/yaml_backups/ until removed. After the next addon/package upgrade containing the fix, the integration will run this cleanup automatically and surface a persistent notification with the same rotation guidance.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ha-mcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-552"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T20:17:23Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nWhen `ENABLE_YAML_CONFIG_EDITING=true`, every `ha_config_set_yaml` call backs up the pre-edit file to `\u003cconfig\u003e/www/yaml_backups/`, which Home Assistant serves at `/local/` with **no authentication**. Anyone who can reach the HA web interface can download the most recent pre-edit `configuration.yaml` (or other YAML file) \u2014 typically containing plaintext MQTT passwords, REST credentials, webhook IDs, geofence coordinates, and `shell_command` definitions \u2014 with zero credentials.\n\n### Details\n\nThe backup feature is good \u2014 `do_backup` defaults to `True` and protects users from a bad edit. The issue is the location:\n\n- `custom_components/ha_mcp_tools/__init__.py:596` \u2014 `backup_dir = config_dir / \"www\" / \"yaml_backups\"`\n- `custom_components/ha_mcp_tools/__init__.py:602` \u2014 `backup_file = backup_dir / f\"{safe_name}.{timestamp}.bak\"`\n- `custom_components/ha_mcp_tools/__init__.py:606-607,692-693` \u2014 backup path returned to caller and logged at INFO\n\n`\u003cconfig\u003e/www/` is `/local/` and HA serves it unauthenticated by design (intended for static dashboard assets). An attacker discovers the path three ways: (1) it\u0027s returned to the MCP client in `result[\"backup_path\"]`; (2) it\u0027s logged at INFO and recoverable via `ha_get_logs`; (3) the timestamp format is `%Y%m%d_%H%M%S` \u2014 86,400 candidates per day, enumerable. Backups accumulate (no rotation), so a long-running install holds a chronological history.\n\n**Preconditions:** `ENABLE_YAML_CONFIG_EDITING=true` (off by default), at least one YAML edit made, and the attacker can reach HA\u0027s port 8123 (LAN, or internet via Nabu Casa / reverse proxy).\n\n### PoC\n\nA pytest E2E test against a fresh Docker HA container with the custom component installed (using the project\u0027s existing `ha_container_with_fresh_config` fixture):\n\n```\n[1] ha_config_set_yaml(yaml_path=\"template\", action=\"add\", ...) \u2192 success=True\n[1] backup_path = \u0027www/yaml_backups/configuration.yaml.20260505_171335.bak\u0027\n[2] GET http://\u003cha\u003e:8123/local/yaml_backups/configuration.yaml.20260505_171335.bak\n (no Authorization header)\n[2] HTTP 200, 440 bytes \u2014 the full pre-edit configuration.yaml\n[control] GET /api/config without auth \u2192 HTTP 401\n```\n\nThe control proves the result is meaningful: the same instance returns 401 for an authenticated endpoint; only `/local/` is unauthenticated by HA design.\n\n### Impact\n\nCWE-552 (Files or Directories Accessible to External Parties). Affects users with `ENABLE_YAML_CONFIG_EDITING=true` who have made at least one YAML edit. Anyone who can reach HA port 8123 reads the most recent pre-edit config without credentials. CVSS 6.5 medium (`AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`); 7.5 high if HA is internet-exposed.\n\n### Resolution\n\nFixed in `7.4.1.dev456` (PR #1180). The fix relocates new backups to `\u003cconfig\u003e/.ha_mcp_tools_backups/` (config root, not served by `/local/`) and adds a one-time migration on integration setup that moves any pre-existing exposed backups, surfaces a persistent notification telling the user to rotate exposed secrets, and removes the legacy directory if empty.\n\nThe fix ships in the next biweekly stable release and is available immediately on the dev channel. Updating to a release containing the fix is sufficient \u2014 no manual action required for users who upgrade.\n\n### Manual cleanup (for users who cannot upgrade yet)\n\nIf you used `ha_config_set_yaml` on a vulnerable version and cannot wait for the next stable release, manually remove the exposed backups:\n\n```\nrm -rf \u003cconfig\u003e/www/yaml_backups/\n```\n\nThen rotate any secrets that may have been in the YAML files those backups captured (MQTT/REST credentials, webhook IDs, `shell_command` definitions, geofence coordinates). The directory is reachable at `http(s)://\u003cha-host\u003e:8123/local/yaml_backups/` until removed. After the next addon/package upgrade containing the fix, the integration will run this cleanup automatically and surface a persistent notification with the same rotation guidance.",
"id": "GHSA-g39v-cvjh-8fpf",
"modified": "2026-05-14T20:17:23Z",
"published": "2026-05-14T20:17:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/homeassistant-ai/ha-mcp/security/advisories/GHSA-g39v-cvjh-8fpf"
},
{
"type": "WEB",
"url": "https://github.com/homeassistant-ai/ha-mcp/pull/1180"
},
{
"type": "WEB",
"url": "https://github.com/homeassistant-ai/ha-mcp/commit/09c524526b5f945638aa97de6218fadcd233023c"
},
{
"type": "PACKAGE",
"url": "https://github.com/homeassistant-ai/ha-mcp"
},
{
"type": "WEB",
"url": "https://github.com/homeassistant-ai/ha-mcp/releases/tag/v7.4.1.dev456"
},
{
"type": "WEB",
"url": "https://github.com/homeassistant-ai/ha-mcp/releases/tag/v7.5.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Home Assistant MCP Server: YAML config backups written under www/ are served unauthenticated at /local/"
}
GHSA-G3CQ-F9XX-GC5G
Vulnerability from github – Published: 2026-04-12 15:30 – Updated: 2026-04-12 15:30CF Image Hosting Script 1.6.5 allows unauthenticated attackers to download and decode the application database by accessing the imgdb.db file in the upload/data directory. Attackers can extract delete IDs stored in plaintext from the deserialized database and use them to delete all pictures via the d parameter.
{
"affected": [],
"aliases": [
"CVE-2019-25709"
],
"database_specific": {
"cwe_ids": [
"CWE-552"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-12T13:16:33Z",
"severity": "CRITICAL"
},
"details": "CF Image Hosting Script 1.6.5 allows unauthenticated attackers to download and decode the application database by accessing the imgdb.db file in the upload/data directory. Attackers can extract delete IDs stored in plaintext from the deserialized database and use them to delete all pictures via the d parameter.",
"id": "GHSA-g3cq-f9xx-gc5g",
"modified": "2026-04-12T15:30:27Z",
"published": "2026-04-12T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25709"
},
{
"type": "WEB",
"url": "https://davidtavarez.github.io"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/46094"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/cf-image-hosting-script-unauthorized-database-access"
},
{
"type": "WEB",
"url": "http://forum.codefuture.co.uk/showthread.php?tid=73141"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-G3PR-2XQQ-VJ3C
Vulnerability from github – Published: 2025-04-09 12:30 – Updated: 2025-04-09 12:30CWE-552: Files or Directories Accessible to External Parties vulnerability over https exists that could leak information and potential privilege escalation following man in the middle attack.
{
"affected": [],
"aliases": [
"CVE-2025-2222"
],
"database_specific": {
"cwe_ids": [
"CWE-552"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-09T11:15:42Z",
"severity": "HIGH"
},
"details": "CWE-552: Files or Directories Accessible to External Parties vulnerability over https exists that could leak\ninformation and potential privilege escalation following man in the middle attack.",
"id": "GHSA-g3pr-2xqq-vj3c",
"modified": "2025-04-09T12:30:24Z",
"published": "2025-04-09T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2222"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2025-098-01\u0026p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2025-098-01.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-G3WG-6MCF-8JJ6
Vulnerability from github – Published: 2020-11-04 17:50 – Updated: 2023-11-27 23:07Impact
On Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability.
Additionally, any user code uses of WebAppContext::getTempDirectory would similarly be vulnerable.
Additionally, any user application code using the ServletContext attribute for the tempdir will also be impacted.
See: https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ServletContext.html#TEMPDIR
For example:
import java.io.File;
import java.io.IOException;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class ExampleServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
File tempDir = (File)getServletContext().getAttribute(ServletContext.TEMPDIR); // Potentially compromised
// do something with that temp dir
}
}
Example: The JSP library itself will use the container temp directory for compiling the JSP source into Java classes before executing them.
CVSSv3.1 Evaluation
This vulnerability has been calculated to have a CVSSv3.1 score of 7.8/10 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Patches
Fixes were applied to the 9.4.x branch with: - https://github.com/eclipse/jetty.project/commit/53e0e0e9b25a6309bf24ee3b10984f4145701edb - https://github.com/eclipse/jetty.project/commit/9ad6beb80543b392c91653f6bfce233fc75b9d5f
These will be included in releases: 9.4.33, 10.0.0.beta3, 11.0.0.beta3
Workarounds
A work around is to set a temporary directory, either for the server or the context, to a directory outside of the shared temporary file system.
For recent releases, a temporary directory can be created simple by creating a directory called work in the ${jetty.base} directory (the parent directory of the webapps directory).
Alternately the java temporary directory can be set with the System Property java.io.tmpdir. A more detailed description of how jetty selects a temporary directory is below.
The Jetty search order for finding a temporary directory is as follows:
- If the
WebAppContexthas a temp directory specified, use it. - If the
ServletContexthas thejavax.servlet.context.tempdirattribute set, and if directory exists, use it. - If a
${jetty.base}/workdirectory exists, use it (since Jetty 9.1) - If a
ServletContexthas theorg.eclipse.jetty.webapp.basetempdirattribute set, and if the directory exists, use it. - Use
System.getProperty("java.io.tmpdir")and use it.
Jetty will end traversal at the first successful step. To mitigate this vulnerability the directory must be set to one that is not writable by an attacker. To avoid information leakage, the directory should also not be readable by an attacker.
Setting a Jetty server temporary directory.
Choices 3 and 5 apply to the server level, and will impact all deployed webapps on the server.
For choice 3 just create that work directory underneath your ${jetty.base} and restart Jetty.
For choice 5, just specify your own java.io.tmpdir when you start the JVM for Jetty.
[jetty-distribution]$ java -Djava.io.tmpdir=/var/web/work -jar start.jar
Setting a Context specific temporary directory.
The rest of the choices require you to configure the context for that deployed webapp (seen as ${jetty.base}/webapps/<context>.xml)
Example (excluding the DTD which is version specific):
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
<Set name="contextPath"><Property name="foo"/></Set>
<Set name="war">/var/web/webapps/foo.war</Set>
<Set name="tempDirectory">/var/web/work/foo</Set>
</Configure>
References
- https://github.com/eclipse/jetty.project/issues/5451
- CWE-378: Creation of Temporary File With Insecure Permissions
- CWE-379: Creation of Temporary File in Directory with Insecure Permissions
- CodeQL Query PR To Detect Similar Vulnerabilities
Similar Vulnerabilities
Similar, but not the same.
- JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp
- Google Guava - https://github.com/google/guava/issues/4011
- Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945
- JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
For more information
The original report of this vulnerability is below:
On Thu, 15 Oct 2020 at 21:14, Jonathan Leitschuh jonathan.leitschuh@gmail.com wrote: Hi WebTide Security Team,
I'm a security researcher writing some custom CodeQL queries to find Local Temporary Directory Hijacking Vulnerabilities. One of my queries flagged an issue in Jetty.
https://lgtm.com/query/5615014766184643449/
I've recently been looking into security vulnerabilities involving the temporary directory because on unix-like systems, the system temporary directory is shared between all users. There exists a race condition between the deletion of the temporary file and the creation of the directory.
java // ensure file will always be unique by appending random digits tmpDir = File.createTempFile(temp, ".dir", parent); // Attacker knows the full path of the file that will be generated // delete the file that was created tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty. // and make a directory of the same name // SECURITY VULNERABILITY: Race Condition! - Attacker beats Jetty and now owns this directory tmpDir.mkdirs();https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L511-L518
In several cases the
parentparameter will not be the system temporary directory. However, there is one case where it will be, as the last fallback.https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L467-L468
If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability.
Would your team be willing to open a GitHub security advisory to continue the discussion and disclosure there? https://github.com/eclipse/jetty.project/security/advisories
This vulnerability disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first.
Cheers, Jonathan Leitschuh
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-webapp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.4.33.v20201020"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.mortbay.jetty:jetty-webapp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.4.33"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.0.beta2"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-webapp"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0.beta1"
},
{
"fixed": "10.0.0.beta3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.0.beta2"
},
"package": {
"ecosystem": "Maven",
"name": "org.mortbay.jetty:jetty-webapp"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0.beta1"
},
{
"fixed": "10.0.0.beta3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0.beta2"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-webapp"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0.beta1"
},
{
"fixed": "11.0.0.beta3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.0.beta2"
},
"package": {
"ecosystem": "Maven",
"name": "org.mortbay.jetty:jetty-webapp"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0.beta1"
},
{
"fixed": "11.0.0.beta3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-27216"
],
"database_specific": {
"cwe_ids": [
"CWE-378",
"CWE-379",
"CWE-552"
],
"github_reviewed": true,
"github_reviewed_at": "2020-11-04T17:48:31Z",
"nvd_published_at": "2020-10-23T13:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nOn Unix like systems, the system\u0027s temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability.\n\nAdditionally, any user code uses of [WebAppContext::getTempDirectory](https://www.eclipse.org/jetty/javadoc/9.4.31.v20200723/org/eclipse/jetty/webapp/WebAppContext.html#getTempDirectory()) would similarly be vulnerable.\n\nAdditionally, any user application code using the `ServletContext` attribute for the tempdir will also be impacted.\nSee: https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ServletContext.html#TEMPDIR\n\nFor example:\n```java\nimport java.io.File;\nimport java.io.IOException;\nimport javax.servlet.ServletContext;\nimport javax.servlet.ServletException;\nimport javax.servlet.http.HttpServlet;\nimport javax.servlet.http.HttpServletRequest;\nimport javax.servlet.http.HttpServletResponse;\n\npublic class ExampleServlet extends HttpServlet {\n @Override\n protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {\n File tempDir = (File)getServletContext().getAttribute(ServletContext.TEMPDIR); // Potentially compromised\n // do something with that temp dir\n }\n}\n```\n\nExample: The JSP library itself will use the container temp directory for compiling the JSP source into Java classes before executing them.\n\n### CVSSv3.1 Evaluation\n\nThis vulnerability has been calculated to have a [CVSSv3.1 score of 7.8/10 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\u0026version=3.1)\n\n### Patches\nFixes were applied to the 9.4.x branch with:\n- https://github.com/eclipse/jetty.project/commit/53e0e0e9b25a6309bf24ee3b10984f4145701edb\n- https://github.com/eclipse/jetty.project/commit/9ad6beb80543b392c91653f6bfce233fc75b9d5f\n\nThese will be included in releases: 9.4.33, 10.0.0.beta3, 11.0.0.beta3\n\n### Workarounds\n\nA work around is to set a temporary directory, either for the server or the context, to a directory outside of the shared temporary file system.\nFor recent releases, a temporary directory can be created simple by creating a directory called `work` in the ${jetty.base} directory (the parent directory of the `webapps` directory).\nAlternately the java temporary directory can be set with the System Property `java.io.tmpdir`. A more detailed description of how jetty selects a temporary directory is below.\n\nThe Jetty search order for finding a temporary directory is as follows:\n\n1. If the [`WebAppContext` has a temp directory specified](https://www.eclipse.org/jetty/javadoc/current/org/eclipse/jetty/webapp/WebAppContext.html#setTempDirectory(java.io.File)), use it.\n2. If the `ServletContext` has the `javax.servlet.context.tempdir` attribute set, and if directory exists, use it.\n3. If a `${jetty.base}/work` directory exists, use it (since Jetty 9.1)\n4. If a `ServletContext` has the `org.eclipse.jetty.webapp.basetempdir` attribute set, and if the directory exists, use it.\n5. Use `System.getProperty(\"java.io.tmpdir\")` and use it.\n\nJetty will end traversal at the first successful step.\nTo mitigate this vulnerability the directory must be set to one that is not writable by an attacker. To avoid information leakage, the directory should also not be readable by an attacker.\n\n#### Setting a Jetty server temporary directory.\n\nChoices 3 and 5 apply to the server level, and will impact all deployed webapps on the server.\n\nFor choice 3 just create that work directory underneath your `${jetty.base}` and restart Jetty.\n\nFor choice 5, just specify your own `java.io.tmpdir` when you start the JVM for Jetty.\n\n``` shell\n[jetty-distribution]$ java -Djava.io.tmpdir=/var/web/work -jar start.jar\n```\n\n#### Setting a Context specific temporary directory.\n\nThe rest of the choices require you to configure the context for that deployed webapp (seen as `${jetty.base}/webapps/\u003ccontext\u003e.xml`)\n\nExample (excluding the DTD which is version specific):\n\n``` xml\n\u003cConfigure class=\"org.eclipse.jetty.webapp.WebAppContext\"\u003e\n \u003cSet name=\"contextPath\"\u003e\u003cProperty name=\"foo\"/\u003e\u003c/Set\u003e\n \u003cSet name=\"war\"\u003e/var/web/webapps/foo.war\u003c/Set\u003e\n \u003cSet name=\"tempDirectory\"\u003e/var/web/work/foo\u003c/Set\u003e\n\u003c/Configure\u003e\n```\n\n### References\n \n - https://github.com/eclipse/jetty.project/issues/5451\n - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html)\n - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html)\n - [CodeQL Query PR To Detect Similar Vulnerabilities](https://github.com/github/codeql/pull/4473)\n\n### Similar Vulnerabilities\n\nSimilar, but not the same.\n\n - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp\n - Google Guava - https://github.com/google/guava/issues/4011\n - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945\n - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824\n\n### For more information\n\nThe original report of this vulnerability is below:\n\n\u003e On Thu, 15 Oct 2020 at 21:14, Jonathan Leitschuh \u003cjonathan.leitschuh@gmail.com\u003e wrote:\n\u003e Hi WebTide Security Team,\n\u003e\n\u003e I\u0027m a security researcher writing some custom CodeQL queries to find Local Temporary Directory Hijacking Vulnerabilities. One of my queries flagged an issue in Jetty.\n\u003e\n\u003e https://lgtm.com/query/5615014766184643449/\n\u003e\n\u003e I\u0027ve recently been looking into security vulnerabilities involving the temporary directory because on unix-like systems, the system temporary directory is shared between all users.\n\u003e There exists a race condition between the deletion of the temporary file and the creation of the directory.\n\u003e\n\u003e ```java\n\u003e // ensure file will always be unique by appending random digits\n\u003e tmpDir = File.createTempFile(temp, \".dir\", parent); // Attacker knows the full path of the file that will be generated\n\u003e // delete the file that was created\n\u003e tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty.\n\u003e // and make a directory of the same name\n\u003e // SECURITY VULNERABILITY: Race Condition! - Attacker beats Jetty and now owns this directory\n\u003e tmpDir.mkdirs();\n\u003e ```\n\u003e\n\u003e https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L511-L518\n\u003e\n\u003e In several cases the `parent` parameter will not be the system temporary directory. However, there is one case where it will be, as the last fallback.\n\u003e\n\u003e\n\u003e https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L467-L468\n\u003e\n\u003e If any code is ever executed out of this temporary directory, this can lead to a local privilege\u00a0escalation vulnerability.\n\u003e\n\u003e Would your team be willing to open a GitHub security advisory to continue the discussion and disclosure there?\u00a0https://github.com/eclipse/jetty.project/security/advisories\n\u003e\n\u003e **This vulnerability disclosure follows Google\u0027s [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I\u0027m not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first.**\n\u003e\n\u003e Cheers,\n\u003e Jonathan Leitschuh\n\n\n",
"id": "GHSA-g3wg-6mcf-8jj6",
"modified": "2023-11-27T23:07:50Z",
"published": "2020-11-04T17:50:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6"
},
{
"type": "WEB",
"url": "https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6#advisory-comment-63053"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27216"
},
{
"type": "WEB",
"url": "https://github.com/eclipse/jetty.project/issues/5451"
},
{
"type": "WEB",
"url": "https://github.com/github/codeql/pull/4473"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raa9c370ab42d737e93bc1795bb6a2187d7c60210cd5e3b3ce8f3c484@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rad255c736fad46135f1339408cb0147d0671e45c376c3be85ceeec1a@%3Cnotifications.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rae15d73cabef55bad148e4e6449b05da95646a2a8db3fc938e858dff@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raf9c581b793c30ff8f55f2415c7bd337eb69775aae607bf9ed1b16fb@%3Cdev.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rafb023a7c61180a1027819678eb2068b0b60cd5c2559cb8490e26c81@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb077d35f2940191daeefca0d6449cddb2e9d06bcf8f5af4da2df3ca2@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb5f2558ea2ac63633dfb04db1e8a6ea6bb1a2b8614899095e16c6233@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb69b1d7008a4b3de5ce5867e41a455693907026bc70ead06867aa323@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb7e159636b26156f6ef2b2a1a79b3ec9a026923b5456713e68f7c18e@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb81a018f83fe02c95a2138a7bb4f1e1677bd7e1fc1e7024280c2292d@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb8ad3745cb94c60d44cc369aff436eaf03dbc93112cefc86a2ed53ba@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb8c007f87dc57731a7b9a3b05364530422535b7e0bc6a0c5b68d4d55@%3Cdev.felix.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbc5a622401924fadab61e07393235838918228b3d8a1a6704295b032@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbc5a8d7a0a13bc8152d427a7e9097cdeb139c6cfe111b2f00f26d16b@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbf99e4495461099cad9aa62e0164f8f25a7f97b791b4ace56e375f8d@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc1646894341450fdc4f7e96a88f5e2cf18d8004714f98aec6b831b3e@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc1d9b8e9d17749d4d2b9abaaa72c422d090315bd6bc0ae73a16abc1c@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re08b03cd1754b32f342664eead415af48092c630c8e3e0deba862a26@%3Ccommits.shiro.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r1d45051310b11c6d6476f20d71b08ea97cb76846cbf61d196bac1c3f@%3Cdev.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8cacf91ae1b17cc6531d20953c52fa52f6fd3191deb3383446086ab7@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8dd01541fc49d24ec223365a9974231cbd7378b749247a89b0a52210@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8fead0144bb84d8714695c43607dca9c5101aa028a431ec695882fe5@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r90b5ac6e2bf190a5297bda58c7ec76d01cd86ff050b2470fcd9f4b35@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r911c1879258ebf98bca172c0673350eb7ea6569ca1735888d4cb7adc@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r916b6542bd5b15a8a7ff8fc14a0e0331e8e3e9d682f22768ae71d775@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r93b240be16e642579ed794325bae31b040e1af896ecc12466642e19d@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r93d5e81e879120d8d87925dbdd4045cb3afa9b066f4370f60b626ce3@%3Ccommits.druid.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9b790fe3a93121199f41258474222f15002b2f729495aa7ecbf90718@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9c010b79140452294292379183e7fe8e3533c5bb4db3f3fb39a6df61@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9cc76b98f87738791b8ec3736755f92444d3c8cb26bd4e4ffdb5c1cc@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9cd444f944241dc26d9b8b007fe8971ed7f005b56befef7a4f4fb827@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9d9b4b93df7f92cdf1147db0fc169be1776c93d1fbc63bc65721fffd@%3Cdev.knox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9f8c45a2a4540911cd8bd0485f67e8091883c9234d7a3aeb349c46c1@%3Creviews.iotdb.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra1f19625cc67ac1b459c558f2ea5647d71ce51c6fe4f4cb03baec849@%3Cnotifications.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra55e04d5a73afcb8383f4386e2b26832c6e3972e53827021ab885943@%3Ccommits.shiro.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra5b7313d8cc9411db6790adfba33f2cf0665cb77adb7b02043c95867@%3Cdev.felix.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re5706141ca397587f7ee0f500a39ccc590a41f802fc125fc135cb92f@%3Cnotifications.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ree506849c4f04376793b1a3076bc017da60b8a2ef2702dc214ff826f@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/refbbb0eb65c185d1fa491cee08ac8ed32708ce3b269133a6da264317@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf00ea6376f3d0e8b8f62cf6d4a4f28b24e27193acd2c851f618aa41e@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf3bc023a7cc729aeac72f482e2eeeab9008aa6b1dadbeb3f45320cae@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfd9f102864a039f7fda64a580dfe1a342d65d7b723ca06dc9fbceb31@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfe5caef1fd6cf4b8ceac1b63c33195f2908517b665c946c020d3fbd6@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfe6ba83d14545e982400dea89e68b10113cb5202a3dcb558ce64842d@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rff0ad6a7dac2182421e2db2407e44fbb61a89904adfd91538f21fbf8@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/05/msg00016.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20201123-0005"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4949"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc2e24756d28580eeac811c5c6a12012c9f424b6e5bffb89f98ee3d03@%3Cdev.felix.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc44d1147f78496ec9932a38b28795ff4fd0c4fa6e3b6f5cc33c14d29@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc4b972ea10c5a65c6a88a6e233778718ab9af7f484affdd5e5de0cff@%3Ccommits.felix.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc77918636d8744d50312e4f67ba2e01f47db3ec5144540df8745cb38@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc8dd95802be0cca8d7d0929c0c8484ede384ecb966b2a9dc7197b089@%3Creviews.iotdb.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc9d2ab8a6c7835182f20b01104798e67c75db655c869733a0713a590@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rccedec4cfd5df6761255b71349e3b7c27ee0745bd33698a71b1775cf@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcdcf32952397c83a1d617a8c9cd5c15c98b8d0d38a607972956bde7e@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcdd56ab4255801a0964dcce3285e87f2c6994e6469e189f6836f34e3@%3Cnotifications.iotdb.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcfb95a7c69c4b9c082ea1918e812dfc45aa0d1e120fd47f68251a336@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcff5caebfd535195276aaabc1b631fd55a4ff6b14e2bdfe33f18ff91@%3Creviews.iotdb.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd0e44e8ef71eeaaa3cf3d1b8b41eb25894372e2995ec908ce7624d26@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd58b60ab2e49ebf21022e59e280feb25899ff785c88f31fe314aa5b9@%3Ccommits.shiro.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd7e62e2972a41c2658f41a824b8bdd15644d80fcadc51fe7b7c855de@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rdbf1cd0ab330c032f3a09b453cb6405dccc905ad53765323bddab957@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rdddb4b06e86fd58a1beda132f22192af2f9b56aae8849cb3767ccd55@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rde11c433675143d8d27551c3d9e821fe1955f1551a518033d3716553@%3Cdev.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rde782fd8e133f7e04e50c8aaa4774df524367764eb5b85bf60d96747@%3Cnotifications.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r1dbb87c9255ecefadd8de514fa1d35c1d493c0527d7672cf40505d04@%3Ccommits.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r1ed79516bd6d248ea9f0e704dbfd7de740d5a75b71c7be8699fec824@%3Cnotifications.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r1ef28b89ff0281c87ba3a7659058789bf28a99b8074191f1c3678db8@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r1fe31643fc34b4a33ae3d416d92c271aa97663f1782767d25e1d9ff8@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2122537d3f9beb0ce59f44371a951b226406719919656ed000984bd0@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r279254a1bd6434c943da52000476f307e62b6910755387aeca1ec9a1@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2aa316d008dab9ae48350b330d15dc1b863ea2a933558fbfc42b91a6@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2d17b2a4803096ba427f3575599ea29b55f5cf9dbc1f12ba044cae1a@%3Cnotifications.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2e02700f7cfecb213de50be83e066086bea90278cd753db7fdc2ccff@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2f732ee49d00610683ab5ddb4692ab25136b00bfd132ca3a590218a9@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3042a9dd2973aa229e52d022df7813e4d74b67df73bfa6d97bb0caf8@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r336b1694a01858111e4625fb9ab2b07ad43a64a525cf6402e06aa6bf@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r351298dd39fc1ab63303be94b0c0d08acd72b17448e0346d7386189b@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r352e40ca9874d1beb4ad95403792adca7eb295e6bc3bd7b65fabcc21@%3Ccommits.samza.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r382870d6ccfd60533eb0d980688261723ed8a0704dafa691c4e9aa68@%3Ccommits.iotdb.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3a763de620be72b6d74f46ec4bf39c9f35f8a0b39993212c0ac778ec@%3Ccommits.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3b0ce1549a1ccdd7e51ec66daf8d54d46f1571edbda88ed09c96d7da@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://bugs.eclipse.org/bugs/show_bug.cgi?id=567921"
},
{
"type": "WEB",
"url": "https://cwe.mitre.org/data/definitions/378.html"
},
{
"type": "WEB",
"url": "https://cwe.mitre.org/data/definitions/379.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse/jetty.project"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0259b14ae69b87821e27fed1f5333ea86018294fd31aab16b1fac84e@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r07525dc424ed69b3919618599e762f9ac03791490ca9d724f2241442@%3Cdev.felix.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r09b345099b4f88d2bed7f195a96145849243fb4e53661aa3bcf4c176@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0d7ad4f02c44d5d53a9ffcbca7ff4a8138241322da9c5c35b5429630@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0d95e01f52667f44835c40f6dea72bb4397f33cd70a564ea74f3836d@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0df8fe10fc36028cf6d0381ab66510917d0d68bc5ef7042001d03830@%3Cdev.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0e9efe032cc65433251ee6470c66c334d4e7db9101e24cf91a3961f2@%3Ccommits.directory.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0f5e9b93133ef3aaf31484bc3e15cc4b85f8af0fe4de2dacd9379d72@%3Cdev.felix.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r100c5c7586a23a19fdb54d8a32e17cd0944bdaa46277b35c397056f6@%3Cnotifications.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r171846414347ec5fed38241a9f8a009bd2c89d902154c6102b1fb39a@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r185d10aae8161c08726f3ba9a1f1c47dfb97624ea6212fa217173204@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r18b6f10d9939419bae9c225d5058c97533cb376c9d6d0a0733ddd48d@%3Cnotifications.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r19e8b338af511641d211ff45c43646fe1ae19dc9897d69939c09cabe@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r1d40368a309f9d835dcdd900249966e4fcbdf98c1cc4c84db2cd9964@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6b83ca85c8f9a6794b1f85bc70d1385ed7bc1ad07750d0977537154a@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6dfa64ecc3d67c1a71c08bfa04064549179d499f8e20a8285c57bd51@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6f51a654ac2e67e3d1c65a8957cbbb127c3f15b64b4fcd626df03633@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r70f8bcccd304bd66c1aca657dbfc2bf11f73add9032571b01f1f733d@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r71da5f51ef04cb95abae560425dce9667740cbd567920f516f76efb7@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r73b5a9b677b707bbb7c1469ea746312c47838b312603bada9e382bba@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r761a52f1e214efec286ee80045d0012e955eebaa72395ad62cccbcfc@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r769411eb43dd9ef77665700deb7fc491fc3ceb532914260c90b56f2f@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r77dd041d8025a869156481d2268c67ad17121f64e31f9b4a1a220145@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7bdc83513c12db1827b79b8d57a7a0975a25d28bc6c5efe590ec1e02@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7da5ae60d7973e8894cfe92f49ecb5b47417eefab4c77cc87514d3cf@%3Cdev.felix.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8045eedd6bb74efcd8e01130796adbab98ee4a0d1273509fb1f2077a@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r819857361f5a156e90d6d06ccf6c41026bc99030d60d0804be3a9957@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r827d17bf6900eddc686f4b6ee16fc5e52ca0070f8df7612222c40ac5@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r874688141495df766e62be095f1dfb0bf4a24ca0340d8e0215c03fab@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r87b0c69fef09277333a7e1716926d1f237d462e143a335854ddd922f@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r87d8337300a635d66f0bb838bf635cdfcbba6b92c608a7813adbf4f4@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8866f0cd2a3b319288b7eea20ac137b9f260c813d10ee2db88b65d32@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3e05ab0922876e74fea975d70af82b98580f4c14ba643c4f8a9e3a94@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3f32cb4965239399c22497a0aabb015b28b2372d4897185a6ef0ccd7@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r407c316f6113dfc76f7bb3cb1693f08274c521064a92e5214197548e@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4179c71908778cc0598ee8ee1eaed9b88fc5483c65373f45e087f650@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r44115ebfbf3b7d294d7a75f2d30bcc822dab186ebbcc2dce11915ca9@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4946ffd86ad6eb7cb7863311235c914cb41232380de8d9dcdb3c115c@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4f29fb24639ebc5d15fc477656ebc2b3aa00fcfbe197000009c26b40@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r503045a75f4419d083cb63ac89e765d6fb8b10c7dacc0c54fce07cff@%3Creviews.iotdb.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r547bb14c88c5da2588d853ed3030be0109efa537dd797877dff14afd@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5494fdaf4a0a42a15c49841ba7ae577d466d09239ee1050458da0f29@%3Cjira.kafka.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r556787f1ab14da034d79dfff0c123c05877bbe89ef163fd359b4564c@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r568d354961fa88f206dc345411fb11d245c6dc1a8da3e80187fc6706@%3Cdev.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r58f5b14dc5ae43583db3a7e872419aca97ebe47bcd7f7334f4128016@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r59e0878013d329dcc481eeafebdb0ee445b1e2852d0c4827b1ddaff2@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5a07f274f355c914054c7357ad6d3456ffaca064f26cd780acb90a9a@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5a9462096c71593e771602beb0e69357adb5175d9a5c18d5181e0ab4@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6236ae4adc401e3b2f2575c22865f2f6c6ea9ff1d7b264b40d9602af@%3Cissues.beam.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r66e99d973fd79ddbcb3fbdb24f4767fe9b911f5b0abb05d7b6f65801@%3Ccommits.zookeeper.apache.org%3E"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Local Temp Directory Hijacking Vulnerability"
}
GHSA-G487-4FJG-H9J4
Vulnerability from github – Published: 2023-11-17 06:31 – Updated: 2023-11-24 18:30CLUSTERPRO X Ver5.1 and earlier and EXPRESSCLUSTER X 5.1 and earlier, CLUSTERPRO X SingleServerSafe 5.0 and earlier, EXPRESSCLUSTER X SingleServerSafe 5.0 and earlier allows a attacker to log in to the product may execute an arbitrary command.
{
"affected": [],
"aliases": [
"CVE-2023-39545"
],
"database_specific": {
"cwe_ids": [
"CWE-552"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-17T06:15:33Z",
"severity": "HIGH"
},
"details": "CLUSTERPRO X Ver5.1 and earlier and EXPRESSCLUSTER X 5.1 and earlier, CLUSTERPRO X SingleServerSafe 5.0 and earlier, EXPRESSCLUSTER X SingleServerSafe 5.0 and earlier allows a attacker to log in to the product may execute an arbitrary command.\n\n",
"id": "GHSA-g487-4fjg-h9j4",
"modified": "2023-11-24T18:30:30Z",
"published": "2023-11-17T06:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39545"
},
{
"type": "WEB",
"url": "https://jpn.nec.com/security-info/secinfo/nv23-009_en.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G6VV-79QP-W952
Vulnerability from github – Published: 2022-05-24 16:57 – Updated: 2024-04-04 02:09A binary planting in SAP SQL Anywhere, before version 17.0, SAP IQ, before version 16.1, and SAP Dynamic Tier, before versions 1.0 and 2.0, can result in the inadvertent access of files located in directories outside of the paths specified by the user.
{
"affected": [],
"aliases": [
"CVE-2019-0381"
],
"database_specific": {
"cwe_ids": [
"CWE-552"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-08T20:15:00Z",
"severity": "MODERATE"
},
"details": "A binary planting in SAP SQL Anywhere, before version 17.0, SAP IQ, before version 16.1, and SAP Dynamic Tier, before versions 1.0 and 2.0, can result in the inadvertent access of files located in directories outside of the paths specified by the user.",
"id": "GHSA-g6vv-79qp-w952",
"modified": "2024-04-04T02:09:41Z",
"published": "2022-05-24T16:57:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0381"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/2792430"
},
{
"type": "WEB",
"url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=528123050"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G8J6-MW28-V33X
Vulnerability from github – Published: 2022-07-31 00:00 – Updated: 2022-08-11 00:00Trend Micro VPN Proxy Pro version 5.2.1026 and below contains a vulnerability involving some overly permissive folders in a key directory which could allow a local attacker to obtain privilege escalation on an affected system.
{
"affected": [],
"aliases": [
"CVE-2022-33158"
],
"database_specific": {
"cwe_ids": [
"CWE-552"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-30T00:15:00Z",
"severity": "HIGH"
},
"details": "Trend Micro VPN Proxy Pro version 5.2.1026 and below contains a vulnerability involving some overly permissive folders in a key directory which could allow a local attacker to obtain privilege escalation on an affected system.",
"id": "GHSA-g8j6-mw28-v33x",
"modified": "2022-08-11T00:00:43Z",
"published": "2022-07-31T00:00:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33158"
},
{
"type": "WEB",
"url": "https://helpcenter.trendmicro.com/en-us/article/tmka-11042"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-22-853"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.
CAPEC-150: Collect Data from Common Resource Locations
An adversary exploits well-known locations for resources for the purposes of undermining the security of the target. In many, if not most systems, files and resources are organized in a default tree structure. This can be useful for adversaries because they often know where to look for resources or files that are necessary for attacks. Even when the precise location of a targeted resource may not be known, naming conventions may indicate a small area of the target machine's file tree where the resources are typically located. For example, configuration files are normally stored in the /etc director on Unix systems. Adversaries can take advantage of this to commit other types of attacks.
CAPEC-639: Probe System Files
An adversary obtains unauthorized information due to improperly protected files. If an application stores sensitive information in a file that is not protected by proper access control, then an adversary can access the file and search for sensitive information.