CWE-59
AllowedImproper Link Resolution Before File Access ('Link Following')
Abstraction: Base · Status: Draft
The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.
1990 vulnerabilities reference this CWE, most recent first.
GHSA-HC8W-F35H-8RRJ
Vulnerability from github – Published: 2022-09-20 00:00 – Updated: 2022-09-23 00:00Trend Micro Security 2022 (consumer) has a link following vulnerability where an attacker with lower privileges could manipulate a mountpoint which could lead to escalation of privilege on an affected machine.
{
"affected": [],
"aliases": [
"CVE-2022-34893"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-19T18:15:00Z",
"severity": "HIGH"
},
"details": "Trend Micro Security 2022 (consumer) has a link following vulnerability where an attacker with lower privileges could manipulate a mountpoint which could lead to escalation of privilege on an affected machine.",
"id": "GHSA-hc8w-f35h-8rrj",
"modified": "2022-09-23T00:00:41Z",
"published": "2022-09-20T00:00:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34893"
},
{
"type": "WEB",
"url": "https://helpcenter.trendmicro.com/en-us/article/tmka-11053"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-22-1175"
}
],
"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"
}
]
}
GHSA-HCM4-3MHF-GMFH
Vulnerability from github – Published: 2022-05-17 02:18 – Updated: 2022-05-17 02:18rkhunter in rkhunter 1.3.2 allows local users to overwrite arbitrary files via a symlink attack on the /tmp/rkhunter-debug temporary file. NOTE: this is probably a different vulnerability than CVE-2005-1270.
{
"affected": [],
"aliases": [
"CVE-2008-4982"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-11-06T15:55:00Z",
"severity": "MODERATE"
},
"details": "rkhunter in rkhunter 1.3.2 allows local users to overwrite arbitrary files via a symlink attack on the /tmp/rkhunter-debug temporary file. NOTE: this is probably a different vulnerability than CVE-2005-1270.",
"id": "GHSA-hcm4-3mhf-gmfh",
"modified": "2022-05-17T02:18:28Z",
"published": "2022-05-17T02:18:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-4982"
},
{
"type": "WEB",
"url": "https://bugs.gentoo.org/show_bug.cgi?id=235770"
},
{
"type": "WEB",
"url": "https://bugs.gentoo.org/show_bug.cgi?id=235798"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/46511"
},
{
"type": "WEB",
"url": "http://bugs.debian.org/496375"
},
{
"type": "WEB",
"url": "http://dev.gentoo.org/~rbu/security/debiantemp/rkhunter"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2008/10/30/2"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HF8C-7P7W-MCH5
Vulnerability from github – Published: 2022-05-17 03:27 – Updated: 2025-04-12 12:54The abrt-hook-ccpp help program in Automatic Bug Reporting Tool (ABRT) before 2.7.1 allows local users with certain permissions to gain privileges via a symlink attack on a file with a predictable name, as demonstrated by /var/tmp/abrt/abrt-hax-coredump or /var/spool/abrt/abrt-hax-coredump.
{
"affected": [],
"aliases": [
"CVE-2015-5287"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-12-07T18:59:00Z",
"severity": "MODERATE"
},
"details": "The abrt-hook-ccpp help program in Automatic Bug Reporting Tool (ABRT) before 2.7.1 allows local users with certain permissions to gain privileges via a symlink attack on a file with a predictable name, as demonstrated by /var/tmp/abrt/abrt-hax-coredump or /var/spool/abrt/abrt-hax-coredump.",
"id": "GHSA-hf8c-7p7w-mch5",
"modified": "2025-04-12T12:54:26Z",
"published": "2022-05-17T03:27:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-5287"
},
{
"type": "WEB",
"url": "https://github.com/abrt/abrt/commit/3c1b60cfa62d39e5fff5a53a5bc53dae189e740e"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1266837"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/38832"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/154592/ABRT-sosreport-Privilege-Escalation.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2015-2505.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2015/12/01/1"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/linuxbulletinoct2015-2719645.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/78137"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HFP4-CQ95-QV3Q
Vulnerability from github – Published: 2022-05-17 05:01 – Updated: 2022-05-17 05:01asr in Oracle Auto Service Request in Oracle Support Tools before 4.3.2 allows local users to modify arbitrary files via a symlink attack on a predictable filename in /tmp.
{
"affected": [],
"aliases": [
"CVE-2013-1495"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-03-18T21:55:00Z",
"severity": "MODERATE"
},
"details": "asr in Oracle Auto Service Request in Oracle Support Tools before 4.3.2 allows local users to modify arbitrary files via a symlink attack on a predictable filename in /tmp.",
"id": "GHSA-hfp4-cq95-qv3q",
"modified": "2022-05-17T05:01:49Z",
"published": "2022-05-17T05:01:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-1495"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2013/Feb/159"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDVSA-2013:150"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/cpuapr2013-1899555.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HFQ3-3QV2-X5X2
Vulnerability from github – Published: 2023-02-13 09:30 – Updated: 2023-02-23 06:30Dell Command | Integration Suite for System Center, versions before 6.4.0 contain an arbitrary folder delete vulnerability during uninstallation. A locally authenticated malicious user may potentially exploit this vulnerability leading to arbitrary folder deletion.
{
"affected": [],
"aliases": [
"CVE-2023-24572"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-13T08:15:00Z",
"severity": "LOW"
},
"details": "Dell Command | Integration Suite for System Center, versions before 6.4.0 contain an arbitrary folder delete vulnerability during uninstallation. A locally authenticated malicious user may potentially exploit this vulnerability leading to arbitrary folder deletion.",
"id": "GHSA-hfq3-3qv2-x5x2",
"modified": "2023-02-23T06:30:19Z",
"published": "2023-02-13T09:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24572"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000207931/dsa-2023-032"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HFX9-J834-CMXW
Vulnerability from github – Published: 2024-11-23 03:31 – Updated: 2024-11-23 03:31F-Secure Total Link Following Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of F-Secure Total. User interaction on the part of an administrator is required to exploit this vulnerability.
The specific flaw exists within the WithSecure plugin hosting service. By creating a symbolic link, an attacker can abuse the service to create a file. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-23005.
{
"affected": [],
"aliases": [
"CVE-2024-7240"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-22T22:15:16Z",
"severity": "HIGH"
},
"details": "F-Secure Total Link Following Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of F-Secure Total. User interaction on the part of an administrator is required to exploit this vulnerability.\n\nThe specific flaw exists within the WithSecure plugin hosting service. By creating a symbolic link, an attacker can abuse the service to create a file. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-23005.",
"id": "GHSA-hfx9-j834-cmxw",
"modified": "2024-11-23T03:31:58Z",
"published": "2024-11-23T03:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7240"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-24-1012"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HG88-V3CW-3QRH
Vulnerability from github – Published: 2026-05-29 19:45 – Updated: 2026-05-29 19:45Summary
Binary delta apply intermediate-symlink traversal in malicious .delta
Autoupdate/SUBinaryDeltaApply.m enforces relativePath.pathComponents containsObject:@".." and rejects writes whose immediate parent directory IS itself a symbolic link, but does not detect symlinks deeper in the relative path. Autoupdate/SPUSparkleDeltaArchive.m's extractItem: will create symlinks in the destination tree from archive content (no .. check on the symlink target), and a subsequent Extract item targeting <symlink>/foo/bar then escapes the destination tree via fopen(path, "wb") because the kernel resolves the intermediate symlink during the open call.
This is a defense-in-depth issue: exploitation requires a maliciously-crafted .delta that passes EdDSA signature verification, i.e. EdDSA private-key compromise. With the AppInstaller running as root for system-domain installs, it gives the holder of a stolen signing key arbitrary file write at root level via the delta-apply path, which is a strictly broader primitive than the "drop-in replacement bundle" install they would otherwise have.
Affected versions: 1.x (master branch), 2.x branch including 2.9.1.
Details
Symlink writeable from archive
Autoupdate/SPUSparkleDeltaArchive.m:557-678's extractItem: handles symlinks if the archive item carries S_ISLNK(mode):
} else {
// Link files
if (PARTIAL_IO_CHUNK_SIZE < decodedLength) { ...too long... }
if (decodedLength > PATH_MAX) { ...too long... }
char buffer[PATH_MAX + 1] = {0};
if (![self _readBuffer:buffer length:(int32_t)decodedLength]) { ... }
NSString *destinationPath = [fileManager stringWithFileSystemRepresentation:buffer length:decodedLength];
[fileManager removeItemAtPath:itemFilePath error:NULL];
NSError *createLinkError = nil;
if (![fileManager createSymbolicLinkAtPath:itemFilePath withDestinationPath:destinationPath error:&createLinkError]) {
_error = createLinkError;
return NO;
}
...
lchmod(itemFilePathString, mode);
}
The link's destinationPath is taken verbatim from the archive content with only a length cap; absolute paths and .. are accepted. After this item is processed, the destination tree contains a symlink that points outside it.
Parent-symlink check is shallow
Autoupdate/SUBinaryDeltaApply.m:177-207:
[archive enumerateItems:^(SPUDeltaArchiveItem *item, BOOL *stop) {
NSString *relativePath = item.relativeFilePath;
if ([relativePath.pathComponents containsObject:@".."]) {
...reject...
}
NSString *sourceFilePath = [source stringByAppendingPathComponent:relativePath];
NSString *destinationFilePath = [destination stringByAppendingPathComponent:relativePath];
{
NSString *destinationParentDirectory = destinationFilePath.stringByDeletingLastPathComponent;
NSDictionary<NSFileAttributeKey, id> *destinationParentDirectoryAttributes = [fileManager attributesOfItemAtPath:destinationParentDirectory error:NULL];
// It is OK for the directory parent to not exist if it has already been removed
if (destinationParentDirectoryAttributes != nil) {
NSString *fileType = destinationParentDirectoryAttributes[NSFileType];
if ([fileType isEqualToString:NSFileTypeSymbolicLink]) {
...reject...
}
}
}
...
}];
Two gaps:
-
The check inspects only
destinationParentDirectory(one level up), not all intermediate components. For a relative patha/b/c.txt, the kernel resolves through any symlink at componenta.attributesOfItemAtPath:with the resolved path returns attributes of the resolved-through directory, which isNSFileTypeDirectory(notNSFileTypeSymbolicLink), so the check passes. -
The check is skipped entirely if
destinationParentDirectoryAttributes == nil(line 195). When the symlink target is to a directory that does not contain the named subpath, the parent appears not to exist and the check is skipped. The subsequentfopen(path, "wb")then creates the file along the resolved path.
Write primitive
For an item with SPUDeltaItemCommandExtract set, SUBinaryDeltaApply.m:354-365 calls [archive extractItem:item] which goes through SPUSparkleDeltaArchive.m:574-622 for regular files:
[fileManager removeItemAtPath:itemFilePath error:NULL];
char itemFilePathString[PATH_MAX + 1] = {0};
if (![itemFilePath getFileSystemRepresentation:itemFilePathString maxLength:sizeof(itemFilePathString) - 1]) { ... }
FILE *outputFile = fopen(itemFilePathString, "wb");
fopen(path, "wb") follows symlinks at every path component and creates/truncates the file at the resolved path. If <dest>/a is a symlink to /Library/LaunchDaemons (for a root install) and the relative path is a/com.attacker.plist, the call writes /Library/LaunchDaemons/com.attacker.plist.
The chmod follow-up at SUBinaryDeltaApply.m:335 (chmod(destinationFilePath.fileSystemRepresentation, sourceFileInfo.st_mode)) and SPUSparkleDeltaArchive.m:619 (chmod(itemFilePathString, mode)) likewise follows symlinks, so attacker-chosen permissions land on the attacker-chosen target.
Threat model
This primitive is reachable only when the archive can pass EdDSA signature verification, which requires either:
- The developer's private signing key has been compromised, or
- A separate vulnerability allows bypassing
SUSignatureVerifier(none was identified in this review).
Given a stolen private key, the attacker already has the ability to push a normal full-bundle update. The delta-apply traversal grants strictly more: arbitrary file write into directories outside <destination>. When the AppInstaller runs in the system domain (root), this becomes arbitrary file write as root, which is qualitatively broader than "replace the app bundle".
It is therefore worth fixing as a defense-in-depth measure, even though the prerequisite (key compromise) is itself a worst case.
PoC
The PoC requires a valid EdDSA signature on the malicious .delta archive. With a test signing key under your control (any Sparkle test fixture key), generate a delta as follows:
- Construct the archive payload with two items, in this order, using the
SPUSparkleDeltaArchivewriter (or by hand-assembling the format described inSPUSparkleDeltaArchive.mandSPUDeltaArchiveProtocol.h):
Item 1:
relativeFilePath = "Contents/Resources/escape"
commands = SPUDeltaItemCommandExtract (= 0x02)
mode = S_IFLNK | 0o755 (= 0xA1ED)
payload = "/Library/LaunchDaemons"
Item 2:
relativeFilePath = "Contents/Resources/escape/com.attacker.persistence.plist"
commands = SPUDeltaItemCommandExtract (= 0x02)
mode = S_IFREG | 0o644 (= 0x81A4)
payload = <attacker-chosen LaunchDaemon plist bytes>
-
Sign the archive with the test EdDSA key, publish it as a delta enclosure with matching
sparkle:edSignature, and host it from a feed pointed at by a Sparkle host whose old-bundle public key matches. -
Trigger a system-domain install. The flow:
applyBinaryDeltaenumerates items.- Item 1 passes the
..check (the path components areContents,Resources,escape- no..). The parentContents/Resourcesexists in the source-copy and is a directory, not a symlink. The check passes.extractItem:forS_ISLNK(mode)callscreateSymbolicLinkAtPath:withDestinationPath:and creates<dest>/Contents/Resources/escape -> /Library/LaunchDaemons. - Item 2 passes the
..check. Its parent<dest>/Contents/Resources/escaperesolves through the just-created symlink to/Library/LaunchDaemons, whose attributes are returned asNSFileTypeDirectory(not symlink). The check passes. extractItem:forS_ISREG(mode)doesremoveItemAtPath(no-op, target file does not yet exist) thenfopen("<dest>/Contents/Resources/escape/com.attacker.persistence.plist", "wb"). The kernel resolves the symlink and creates/Library/LaunchDaemons/com.attacker.persistence.plist.-
The hash check at the end of
applyBinaryDelta(getRawHashOfTreeWithVersion(afterHash, finalDestination, ...)) is computed only againstfinalDestination. The file dropped at/Library/LaunchDaemons/is outside that tree and does not affect the hash. The hash check still passes (or, if it does not because the dest tree is missing the file, the dropped LaunchDaemon plist is still left behind - destination cleanup at line 471 only removesfinalDestination, not the escape target). -
Observed result: a root-owned LaunchDaemon plist exists at
/Library/LaunchDaemons/com.attacker.persistence.plist. On next reboot it is launched as root.
A simpler proof-of-concept that does not require a system-domain install: target a user-writable directory (e.g. ~/Library/LaunchAgents/), use a user-domain Sparkle host. The same item-pair lands a user-level LaunchAgent at next login.
Impact
Defense-in-depth gap: the holder of a compromised EdDSA signing key gains a primitive (arbitrary file write at the privilege of the AppInstaller process) that exceeds what an "install a malicious bundle" path provides. For system-domain installs this is arbitrary file write as root, including locations outside the target app bundle (/Library/LaunchDaemons, /etc/... subpaths that exist as directories, /usr/local/, etc.).
Recommended fix: in SUBinaryDeltaApply.m, walk every component of relativePath and reject if any intermediate component is a symlink (or refuse to allow the archive to create symlinks during apply at all, given the limited number of legitimate use cases for symlinks inside an .app bundle and the existing lchmod already in place). Cleanup on failure should also removeTree along the symlink target, not just finalDestination.
{
"affected": [
{
"package": {
"ecosystem": "SwiftURL",
"name": "github.com/sparkle-project/Sparkle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.9.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47121"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T19:45:04Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nBinary delta apply intermediate-symlink traversal in malicious .delta\n\n`Autoupdate/SUBinaryDeltaApply.m` enforces `relativePath.pathComponents containsObject:@\"..\"` and rejects writes whose immediate parent directory IS itself a symbolic link, but does not detect symlinks deeper in the relative path. `Autoupdate/SPUSparkleDeltaArchive.m`\u0027s `extractItem:` will create symlinks in the destination tree from archive content (no `..` check on the symlink target), and a subsequent `Extract` item targeting `\u003csymlink\u003e/foo/bar` then escapes the destination tree via `fopen(path, \"wb\")` because the kernel resolves the intermediate symlink during the open call.\n\nThis is a defense-in-depth issue: exploitation requires a maliciously-crafted `.delta` that passes EdDSA signature verification, i.e. EdDSA private-key compromise. With the AppInstaller running as root for system-domain installs, it gives the holder of a stolen signing key arbitrary file write at root level via the delta-apply path, which is a strictly broader primitive than the \"drop-in replacement bundle\" install they would otherwise have.\n\nAffected versions: 1.x (master branch), 2.x branch including 2.9.1.\n\n## Details\n\n### Symlink writeable from archive\n\n`Autoupdate/SPUSparkleDeltaArchive.m:557-678`\u0027s `extractItem:` handles symlinks if the archive item carries `S_ISLNK(mode)`:\n\n```objc\n} else {\n // Link files\n\n if (PARTIAL_IO_CHUNK_SIZE \u003c decodedLength) { ...too long... }\n if (decodedLength \u003e PATH_MAX) { ...too long... }\n\n char buffer[PATH_MAX + 1] = {0};\n if (![self _readBuffer:buffer length:(int32_t)decodedLength]) { ... }\n\n NSString *destinationPath = [fileManager stringWithFileSystemRepresentation:buffer length:decodedLength];\n\n [fileManager removeItemAtPath:itemFilePath error:NULL];\n\n NSError *createLinkError = nil;\n if (![fileManager createSymbolicLinkAtPath:itemFilePath withDestinationPath:destinationPath error:\u0026createLinkError]) {\n _error = createLinkError;\n return NO;\n }\n ...\n lchmod(itemFilePathString, mode);\n}\n```\n\nThe link\u0027s `destinationPath` is taken verbatim from the archive content with only a length cap; absolute paths and `..` are accepted. After this item is processed, the destination tree contains a symlink that points outside it.\n\n### Parent-symlink check is shallow\n\n`Autoupdate/SUBinaryDeltaApply.m:177-207`:\n\n```objc\n[archive enumerateItems:^(SPUDeltaArchiveItem *item, BOOL *stop) {\n NSString *relativePath = item.relativeFilePath;\n\n if ([relativePath.pathComponents containsObject:@\"..\"]) {\n ...reject...\n }\n\n NSString *sourceFilePath = [source stringByAppendingPathComponent:relativePath];\n NSString *destinationFilePath = [destination stringByAppendingPathComponent:relativePath];\n {\n NSString *destinationParentDirectory = destinationFilePath.stringByDeletingLastPathComponent;\n NSDictionary\u003cNSFileAttributeKey, id\u003e *destinationParentDirectoryAttributes = [fileManager attributesOfItemAtPath:destinationParentDirectory error:NULL];\n\n // It is OK for the directory parent to not exist if it has already been removed\n if (destinationParentDirectoryAttributes != nil) {\n NSString *fileType = destinationParentDirectoryAttributes[NSFileType];\n if ([fileType isEqualToString:NSFileTypeSymbolicLink]) {\n ...reject...\n }\n }\n }\n ...\n}];\n```\n\nTwo gaps:\n\n1. The check inspects only `destinationParentDirectory` (one level up), not all intermediate components. For a relative path `a/b/c.txt`, the kernel resolves through any symlink at component `a`. `attributesOfItemAtPath:` with the resolved path returns attributes of the resolved-through directory, which is `NSFileTypeDirectory` (not `NSFileTypeSymbolicLink`), so the check passes.\n\n2. The check is skipped entirely if `destinationParentDirectoryAttributes == nil` (line 195). When the symlink target is to a directory that does not contain the named subpath, the parent appears not to exist and the check is skipped. The subsequent `fopen(path, \"wb\")` then creates the file along the resolved path.\n\n### Write primitive\n\nFor an item with `SPUDeltaItemCommandExtract` set, `SUBinaryDeltaApply.m:354-365` calls `[archive extractItem:item]` which goes through `SPUSparkleDeltaArchive.m:574-622` for regular files:\n\n```objc\n[fileManager removeItemAtPath:itemFilePath error:NULL];\n\nchar itemFilePathString[PATH_MAX + 1] = {0};\nif (![itemFilePath getFileSystemRepresentation:itemFilePathString maxLength:sizeof(itemFilePathString) - 1]) { ... }\n\nFILE *outputFile = fopen(itemFilePathString, \"wb\");\n```\n\n`fopen(path, \"wb\")` follows symlinks at every path component and creates/truncates the file at the resolved path. If `\u003cdest\u003e/a` is a symlink to `/Library/LaunchDaemons` (for a root install) and the relative path is `a/com.attacker.plist`, the call writes `/Library/LaunchDaemons/com.attacker.plist`.\n\nThe `chmod` follow-up at `SUBinaryDeltaApply.m:335` (`chmod(destinationFilePath.fileSystemRepresentation, sourceFileInfo.st_mode)`) and `SPUSparkleDeltaArchive.m:619` (`chmod(itemFilePathString, mode)`) likewise follows symlinks, so attacker-chosen permissions land on the attacker-chosen target.\n\n### Threat model\n\nThis primitive is reachable only when the archive can pass EdDSA signature verification, which requires either:\n\n- The developer\u0027s private signing key has been compromised, or\n- A separate vulnerability allows bypassing `SUSignatureVerifier` (none was identified in this review).\n\nGiven a stolen private key, the attacker already has the ability to push a normal full-bundle update. The delta-apply traversal grants strictly more: arbitrary file write into directories outside `\u003cdestination\u003e`. When the AppInstaller runs in the system domain (root), this becomes arbitrary file write as root, which is qualitatively broader than \"replace the app bundle\".\n\nIt is therefore worth fixing as a defense-in-depth measure, even though the prerequisite (key compromise) is itself a worst case.\n\n## PoC\n\nThe PoC requires a valid EdDSA signature on the malicious `.delta` archive. With a test signing key under your control (any Sparkle test fixture key), generate a delta as follows:\n\n1. Construct the archive payload with two items, in this order, using the `SPUSparkleDeltaArchive` writer (or by hand-assembling the format described in `SPUSparkleDeltaArchive.m` and `SPUDeltaArchiveProtocol.h`):\n\n```\nItem 1:\n relativeFilePath = \"Contents/Resources/escape\"\n commands = SPUDeltaItemCommandExtract (= 0x02)\n mode = S_IFLNK | 0o755 (= 0xA1ED)\n payload = \"/Library/LaunchDaemons\"\n\nItem 2:\n relativeFilePath = \"Contents/Resources/escape/com.attacker.persistence.plist\"\n commands = SPUDeltaItemCommandExtract (= 0x02)\n mode = S_IFREG | 0o644 (= 0x81A4)\n payload = \u003cattacker-chosen LaunchDaemon plist bytes\u003e\n```\n\n2. Sign the archive with the test EdDSA key, publish it as a delta enclosure with matching `sparkle:edSignature`, and host it from a feed pointed at by a Sparkle host whose old-bundle public key matches.\n\n3. Trigger a system-domain install. The flow:\n - `applyBinaryDelta` enumerates items.\n - Item 1 passes the `..` check (the path components are `Contents`, `Resources`, `escape` - no `..`). The parent `Contents/Resources` exists in the source-copy and is a directory, not a symlink. The check passes. `extractItem:` for `S_ISLNK(mode)` calls `createSymbolicLinkAtPath:withDestinationPath:` and creates `\u003cdest\u003e/Contents/Resources/escape -\u003e /Library/LaunchDaemons`.\n - Item 2 passes the `..` check. Its parent `\u003cdest\u003e/Contents/Resources/escape` resolves through the just-created symlink to `/Library/LaunchDaemons`, whose attributes are returned as `NSFileTypeDirectory` (not symlink). The check passes.\n - `extractItem:` for `S_ISREG(mode)` does `removeItemAtPath` (no-op, target file does not yet exist) then `fopen(\"\u003cdest\u003e/Contents/Resources/escape/com.attacker.persistence.plist\", \"wb\")`. The kernel resolves the symlink and creates `/Library/LaunchDaemons/com.attacker.persistence.plist`.\n - The hash check at the end of `applyBinaryDelta` (`getRawHashOfTreeWithVersion(afterHash, finalDestination, ...)`) is computed only against `finalDestination`. The file dropped at `/Library/LaunchDaemons/` is outside that tree and does not affect the hash. The hash check still passes (or, if it does not because the dest tree is missing the file, the dropped LaunchDaemon plist is still left behind - destination cleanup at line 471 only removes `finalDestination`, not the escape target).\n\n4. Observed result: a root-owned LaunchDaemon plist exists at `/Library/LaunchDaemons/com.attacker.persistence.plist`. On next reboot it is launched as root.\n\nA simpler proof-of-concept that does not require a system-domain install: target a user-writable directory (e.g. `~/Library/LaunchAgents/`), use a user-domain Sparkle host. The same item-pair lands a user-level LaunchAgent at next login.\n\n## Impact\n\nDefense-in-depth gap: the holder of a compromised EdDSA signing key gains a primitive (arbitrary file write at the privilege of the AppInstaller process) that exceeds what an \"install a malicious bundle\" path provides. For system-domain installs this is arbitrary file write as root, including locations outside the target app bundle (`/Library/LaunchDaemons`, `/etc/...` subpaths that exist as directories, `/usr/local/`, etc.).\n\nRecommended fix: in `SUBinaryDeltaApply.m`, walk every component of `relativePath` and reject if any intermediate component is a symlink (or refuse to allow the archive to create symlinks during apply at all, given the limited number of legitimate use cases for symlinks inside an `.app` bundle and the existing `lchmod` already in place). Cleanup on failure should also `removeTree` along the symlink target, not just `finalDestination`.",
"id": "GHSA-hg88-v3cw-3qrh",
"modified": "2026-05-29T19:45:04Z",
"published": "2026-05-29T19:45:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sparkle-project/Sparkle/security/advisories/GHSA-hg88-v3cw-3qrh"
},
{
"type": "PACKAGE",
"url": "https://github.com/sparkle-project/Sparkle"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Sparkle: Binary delta apply intermediate-symlink traversal in malicious .delta"
}
GHSA-HG9W-23HG-6PFV
Vulnerability from github – Published: 2026-02-03 18:30 – Updated: 2026-02-05 15:31The ZSPACE Q2C NAS contains a vulnerability related to incorrect symbolic link following. Attackers can format a USB drive to ext4, create a symbolic link to its root directory, insert the drive into the NAS device's slot, and then access the USB drive's directory mounted on the NAS using the Samba protocol. This allows them to obtain all files within the NAS system and tamper with those files.
{
"affected": [],
"aliases": [
"CVE-2025-69431"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-03T18:16:16Z",
"severity": "CRITICAL"
},
"details": "The ZSPACE Q2C NAS contains a vulnerability related to incorrect symbolic link following. Attackers can format a USB drive to ext4, create a symbolic link to its root directory, insert the drive into the NAS device\u0027s slot, and then access the USB drive\u0027s directory mounted on the NAS using the Samba protocol. This allows them to obtain all files within the NAS system and tamper with those files.",
"id": "GHSA-hg9w-23hg-6pfv",
"modified": "2026-02-05T15:31:09Z",
"published": "2026-02-03T18:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69431"
},
{
"type": "WEB",
"url": "https://www.notion.so/ZSPACE-Incorrect-Symlink-Follow-2c26cf4e528a8087ba14d9b1d31a5bb2?source=copy_link"
}
],
"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"
}
]
}
GHSA-HGX9-224C-3P2X
Vulnerability from github – Published: 2026-06-16 21:31 – Updated: 2026-06-16 21:31Microsoft is aware of an elevation of privilege in the Microsoft Malware Protection Engine in Microsoft Defender publicly referred to as "RoguePlanet ". We are working to provide a high quality security update that addresses this vulnerability. We will provide information in this CVE when the update is available.
{
"affected": [],
"aliases": [
"CVE-2026-50656"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-16T19:16:59Z",
"severity": "HIGH"
},
"details": "Microsoft is aware of an elevation of privilege in the Microsoft Malware Protection Engine in Microsoft Defender publicly referred to as \u0026quot;RoguePlanet \u0026quot;. We are working to provide a high quality security update that addresses this vulnerability. We will provide information in this CVE when the update is available.",
"id": "GHSA-hgx9-224c-3p2x",
"modified": "2026-06-16T21:31:57Z",
"published": "2026-06-16T21:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50656"
},
{
"type": "WEB",
"url": "https://github.com/MSNightmare/RoguePlanet"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50656"
}
],
"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"
}
]
}
GHSA-HH95-R7MJ-C9J5
Vulnerability from github – Published: 2026-06-29 15:32 – Updated: 2026-07-03 15:31attr before version 2.6.0 contains a symlink traversal vulnerability in the getfattr and setfattr utilities that allows local attackers to escalate privileges by replacing a pathname component with a symbolic link during directory hierarchy traversal. Attackers who control a pathname component can redirect getfattr and setfattr operations to arbitrary files by substituting a symlink, leading to local privilege escalation when getfattr or setfattr is invoked by a privileged process over an attacker-controlled path.
{
"affected": [],
"aliases": [
"CVE-2026-54371"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-29T14:16:57Z",
"severity": "HIGH"
},
"details": "attr before version 2.6.0 contains a symlink traversal vulnerability in the getfattr and setfattr utilities that allows local attackers to escalate privileges by replacing a pathname component with a symbolic link during directory hierarchy traversal. Attackers who control a pathname component can redirect getfattr and setfattr operations to arbitrary files by substituting a symlink, leading to local privilege escalation when getfattr or setfattr is invoked by a privileged process over an attacker-controlled path.",
"id": "GHSA-hh95-r7mj-c9j5",
"modified": "2026-07-03T15:31:56Z",
"published": "2026-06-29T15:32:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54371"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34889"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-54371"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2490283"
},
{
"type": "WEB",
"url": "https://cgit.git.savannah.nongnu.org/cgit/attr.git/commit/?id=49f79e947270f06940b9100fa638f85dddc4aa7f"
},
{
"type": "WEB",
"url": "https://cgit.git.savannah.nongnu.org/cgit/attr.git/commit/?id=c440855d6b33446edf4b5eb1a2d892281f15a99b"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-54371.json"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/attr-symlink-traversal-privilege-escalation-via-getfattr-setfattr"
}
],
"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:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/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"
}
]
}
Mitigation MIT-48.1
Strategy: Separation of Privilege
- Follow the principle of least privilege when assigning access rights to entities in a software system.
- Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.
CAPEC-132: Symlink Attack
An adversary positions a symbolic link in such a manner that the targeted user or application accesses the link's endpoint, assuming that it is accessing a file with the link's name.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
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.