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-55X3-X8RQ-MG72
Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2022-05-13 01:19Android 1.0 through 9.0 has Insecure Permissions. The Android bug ID is 77286983.
{
"affected": [],
"aliases": [
"CVE-2018-15835"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-30T18:29:00Z",
"severity": "HIGH"
},
"details": "Android 1.0 through 9.0 has Insecure Permissions. The Android bug ID is 77286983.",
"id": "GHSA-55x3-x8rq-mg72",
"modified": "2022-05-13T01:19:12Z",
"published": "2022-05-13T01:19:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15835"
},
{
"type": "WEB",
"url": "https://wwws.nightwatchcybersecurity.com/2018/11/11/cve-2018-15835"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/150284/Android-5.0-Battery-Information-Broadcast-Information-Disclosure.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2018/Nov/35"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-55X8-QM73-MRFG
Vulnerability from github – Published: 2024-07-16 15:30 – Updated: 2025-01-31 15:30A privilege escalation vulnerability exists in the affected products which could allow a malicious user with basic privileges to access functions which should only be available to users with administrative level privileges. If exploited, an attacker could read sensitive data, and create users. For example, a malicious user with basic privileges could perform critical functions such as creating a user with elevated privileges and reading sensitive information in the “views” section.
{
"affected": [],
"aliases": [
"CVE-2024-6435"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T13:15:13Z",
"severity": "HIGH"
},
"details": "A privilege escalation vulnerability exists in the affected products which could allow a malicious user with basic privileges to access functions which should only be available to users with administrative level privileges. If exploited, an attacker could read sensitive data, and create users. For example, a malicious user with basic privileges could perform critical functions such as creating a user with elevated privileges and reading sensitive information in the \u201cviews\u201d section.",
"id": "GHSA-55x8-qm73-mrfg",
"modified": "2025-01-31T15:30:42Z",
"published": "2024-07-16T15:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6435"
},
{
"type": "WEB",
"url": "https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1681.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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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-56JQ-WF2P-G55V
Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2024-03-21 03:33Kentico 11 through 12 lets attackers upload and explore files without authentication via the cmsmodules/medialibrary/formcontrols/liveselectors/insertimageormedia/tabs_media.aspx URI.
{
"affected": [],
"aliases": [
"CVE-2019-12102"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-22T15:29:00Z",
"severity": "CRITICAL"
},
"details": "Kentico 11 through 12 lets attackers upload and explore files without authentication via the cmsmodules/medialibrary/formcontrols/liveselectors/insertimageormedia/tabs_media.aspx URI.",
"id": "GHSA-56jq-wf2p-g55v",
"modified": "2024-03-21T03:33:38Z",
"published": "2022-05-24T16:46:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12102"
},
{
"type": "WEB",
"url": "https://devnet.kentico.com/download/hotfixes"
},
{
"type": "WEB",
"url": "https://docs.kentico.com/k12/configuring-kentico/configuring-the-environment-for-content-editors/configuring-media-libraries/assigning-permissions-to-media-libraries"
},
{
"type": "WEB",
"url": "https://docs.kentico.com/k12/release-notes-kentico-12"
},
{
"type": "WEB",
"url": "https://github.com/Gr4y21/My-CVE-IDs/blob/master/Kentico%20CMS%20Unauthenticated%20File%20Upload%20and%20File%20Exposure"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-5723-X6CG-HR96
Vulnerability from github – Published: 2022-08-13 00:00 – Updated: 2022-08-19 00:00In Bluetooth, there is a possible way to connect or disconnect bluetooth devices without user awareness due to a missing permission check. This could lead to local escalation of privilege with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-181962588
{
"affected": [],
"aliases": [
"CVE-2022-20330"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-12T15:15:00Z",
"severity": "LOW"
},
"details": "In Bluetooth, there is a possible way to connect or disconnect bluetooth devices without user awareness due to a missing permission check. This could lead to local escalation of privilege with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-181962588",
"id": "GHSA-5723-x6cg-hr96",
"modified": "2022-08-19T00:00:22Z",
"published": "2022-08-13T00:00:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20330"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/android-13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5795-QV38-9394
Vulnerability from github – Published: 2022-04-12 00:00 – Updated: 2022-04-16 00:01A local privilege escalation vulnerability caused by incorrect permission assignment in some directories of the Zyxel AP Configurator (ZAC) version 1.1.4, which could allow an attacker to execute arbitrary code as a local administrator.
{
"affected": [],
"aliases": [
"CVE-2022-0556"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-11T12:15:00Z",
"severity": "HIGH"
},
"details": "A local privilege escalation vulnerability caused by incorrect permission assignment in some directories of the Zyxel AP Configurator (ZAC) version 1.1.4, which could allow an attacker to execute arbitrary code as a local administrator.",
"id": "GHSA-5795-qv38-9394",
"modified": "2022-04-16T00:01:13Z",
"published": "2022-04-12T00:00:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0556"
},
{
"type": "WEB",
"url": "https://www.zyxel.com/support/Zyxel-security-advisory-for-local-privilege-escalation-vulnerability-of-AP-Configurator.shtml"
}
],
"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-57F6-PVX8-HWJ6
Vulnerability from github – Published: 2026-06-26 20:44 – Updated: 2026-06-26 20:44Summary
turso-cli persists the user's Turso platform JWT to settings.json using Viper's default configPermissions of 0o644, leaving the credential file world-readable on standard Linux and macOS systems. Any other local UID on the host can read the file and recover the platform JWT, which grants full Turso platform access scoped to the user's organizations.
Impact
The token in settings.json grants the holder full Turso platform access — create or destroy databases, rotate credentials, exfiltrate data, change billing settings — for any organization the user belongs to.
Because the file is world-readable, the credential is reachable by:
- Cron jobs or daemons running as a different system user on the same host
- Sandboxed CI runners with a mounted home directory
- Containers with a bind-mounted host home
- Co-tenants on a shared multi-user developer or jumpbox host
The file path resolves through configdir.LocalConfig("turso"):
- macOS:
~/Library/Application Support/turso/settings.json - Linux:
~/.config/turso/settings.json(or$XDG_CONFIG_HOME/turso/settings.json)
It contains the platform JWT in plaintext JSON alongside organization and username fields.
Comparable CLIs (gh, aws, docker, gcloud, plus close peers planetscale, neon, upstash) write credential files at 0o600 explicitly, so this is a deviation from the cross-vendor baseline rather than a deliberate trade-off.
Details
The OAuth callback handler stores the platform JWT via the settings layer:
// internal/cmd/auth.go:205-214
jwt, err := callbackServer.Result()
...
settings.SetToken(jwt)
SetToken writes through Viper:
// internal/settings/settings.go:124-127
func (s *Settings) SetToken(token string) {
viper.Set("token", token)
s.changed = true
}
Persistence runs through viper.WriteConfig:
// internal/settings/settings.go:96-101
func TryToPersistChanges() error {
if err := viper.WriteConfig(); err != nil {
return fmt.Errorf("failed to persist turso settings file: %w", err)
}
return nil
}
Viper v1.21.0 (pinned in turso-cli go.mod) initializes configPermissions to os.FileMode(0o644) at viper.go:198 and passes that mode straight to os.OpenFile at viper.go:1688. Without a call to viper.SetConfigPermissions(0o600), the resulting settings.json is created at 0o644.
A grep over the auth-config write path under internal/ returns zero hits for Chmod, 0o600, or 0600, confirming there is no follow-up tightening of the file mode anywhere on the persistence path.
Proof of concept
Minimal reproducer using the same Viper version turso-cli pins (github.com/spf13/viper v1.21.0):
package main
import (
"fmt"
"os"
"path/filepath"
"github.com/spf13/viper"
)
func main() {
dir, _ := os.MkdirTemp("", "viperpoc-*")
defer os.RemoveAll(dir)
viper.SetConfigName("settings")
viper.SetConfigType("json")
viper.AddConfigPath(dir)
viper.Set("token", "FAKE_TURSO_JWT_xxxxxxxxxxxxxxxxxxxx")
viper.Set("organization", "exampleorg")
viper.SafeWriteConfig()
st, _ := os.Stat(filepath.Join(dir, "settings.json"))
fmt.Printf("mode: %o\n", st.Mode()&0o777)
}
$ go run main.go mode: 644
The same SafeWriteConfig / WriteConfig calls turso-cli uses produce the same 0o644 mode in a real turso auth login flow.
Remediation
One-line fix at the existing Viper configuration site in internal/settings/settings.go (around lines 48-50):
viper.SetConfigName("settings")
viper.SetConfigType("json")
viper.AddConfigPath(configPath)
viper.SetConfigPermissions(0o600) // restrict settings.json to owner only
Defense in depth:
- Add
os.Chmod(configFile, 0o600)afterTryToPersistChanges, or on read (as PlanetScale does ininternal/config/config.go— theyStatthe token file and self-heal ifMode() &^ 0o600is nonzero).viper.SetConfigPermissionsapplies only on file creation, so an existing wider-mode file is not tightened otherwise. - Add
os.Chmod(configPath, 0o700)afterconfigdir.MakePath(configPath)(line 43) to close the equivalent gap on the enclosing directory, which is otherwise created under the default umask.
Patch: https://github.com/tursodatabase/turso-cli/commit/ffb914849216ef5a86353b3fa6cee66f33af3b66
Workarounds
Until upgraded, users can tighten the existing files manually:
# Linux
chmod 600 ~/.config/turso/settings.json
chmod 700 ~/.config/turso
# macOS
chmod 600 "$HOME/Library/Application Support/turso/settings.json"
chmod 700 "$HOME/Library/Application Support/turso"
This must be repeated after any operation that recreates the file (e.g.
turso auth login) until the patched version is installed.
Resources
- Patch commit: https://github.com/tursodatabase/turso-cli/commit/ffb914849216ef5a86353b3fa6cee66f33af3b66
- Viper
configPermissionsdefault: https://github.com/spf13/viper/blob/v1.21.0/viper.go#L198 - Viper write path: https://github.com/spf13/viper/blob/v1.21.0/viper.go#L1688
- CWE-276: https://cwe.mitre.org/data/definitions/276.html
- CWE-732: https://cwe.mitre.org/data/definitions/732.html
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.25"
},
"package": {
"ecosystem": "Go",
"name": "github.com/tursodatabase/turso-cli"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.26"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48790"
],
"database_specific": {
"cwe_ids": [
"CWE-276",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T20:44:39Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\n`turso-cli` persists the user\u0027s Turso platform JWT to `settings.json` using Viper\u0027s default `configPermissions` of `0o644`, leaving the credential file world-readable on standard Linux and macOS systems. Any other local UID on the host can read the file and recover the platform JWT, which grants full Turso platform access scoped to the user\u0027s organizations.\n\n### Impact\n\nThe token in `settings.json` grants the holder full Turso platform access \u2014 create or destroy databases, rotate credentials, exfiltrate data, change billing settings \u2014 for any organization the user belongs to.\n\nBecause the file is world-readable, the credential is reachable by:\n\n- Cron jobs or daemons running as a different system user on the same host\n- Sandboxed CI runners with a mounted home directory\n- Containers with a bind-mounted host home\n- Co-tenants on a shared multi-user developer or jumpbox host\n\nThe file path resolves through `configdir.LocalConfig(\"turso\")`:\n\n- macOS: `~/Library/Application Support/turso/settings.json`\n- Linux: `~/.config/turso/settings.json` (or `$XDG_CONFIG_HOME/turso/settings.json`)\n\nIt contains the platform JWT in plaintext JSON alongside `organization` and `username` fields.\n\nComparable CLIs (`gh`, `aws`, `docker`, `gcloud`, plus close peers `planetscale`, `neon`, `upstash`) write credential files at `0o600` explicitly, so this is a deviation from the cross-vendor baseline rather than a deliberate trade-off.\n\n### Details\n\nThe OAuth callback handler stores the platform JWT via the settings layer:\n\n```go\n// internal/cmd/auth.go:205-214\njwt, err := callbackServer.Result()\n...\nsettings.SetToken(jwt)\n```\n\n`SetToken` writes through Viper:\n\n```go\n// internal/settings/settings.go:124-127\nfunc (s *Settings) SetToken(token string) {\n viper.Set(\"token\", token)\n s.changed = true\n}\n```\n\nPersistence runs through `viper.WriteConfig`:\n\n```go\n// internal/settings/settings.go:96-101\nfunc TryToPersistChanges() error {\n if err := viper.WriteConfig(); err != nil {\n return fmt.Errorf(\"failed to persist turso settings file: %w\", err)\n }\n return nil\n}\n```\n\nViper v1.21.0 (pinned in `turso-cli` `go.mod`) initializes `configPermissions` to `os.FileMode(0o644)` at `viper.go:198` and passes that mode straight to `os.OpenFile` at `viper.go:1688`. Without a call to `viper.SetConfigPermissions(0o600)`, the resulting `settings.json` is created at `0o644`.\n\nA `grep` over the auth-config write path under `internal/` returns zero hits for `Chmod`, `0o600`, or `0600`, confirming there is no follow-up tightening of the file mode anywhere on the persistence path.\n\n### Proof of concept\n\nMinimal reproducer using the same Viper version `turso-cli` pins (`github.com/spf13/viper v1.21.0`):\n\n```go\npackage main\n\nimport (\n \"fmt\"\n \"os\"\n \"path/filepath\"\n\n \"github.com/spf13/viper\"\n)\n\nfunc main() {\n dir, _ := os.MkdirTemp(\"\", \"viperpoc-*\")\n defer os.RemoveAll(dir)\n\n viper.SetConfigName(\"settings\")\n viper.SetConfigType(\"json\")\n viper.AddConfigPath(dir)\n\n viper.Set(\"token\", \"FAKE_TURSO_JWT_xxxxxxxxxxxxxxxxxxxx\")\n viper.Set(\"organization\", \"exampleorg\")\n viper.SafeWriteConfig()\n\n st, _ := os.Stat(filepath.Join(dir, \"settings.json\"))\n fmt.Printf(\"mode: %o\\n\", st.Mode()\u00260o777)\n}\n```\n$ go run main.go mode: 644\n\nThe same `SafeWriteConfig` / `WriteConfig` calls `turso-cli` uses produce the same `0o644` mode in a real `turso auth login` flow.\n\n### Remediation\n\nOne-line fix at the existing Viper configuration site in `internal/settings/settings.go` (around lines 48-50):\n\n```go\nviper.SetConfigName(\"settings\")\nviper.SetConfigType(\"json\")\nviper.AddConfigPath(configPath)\nviper.SetConfigPermissions(0o600) // restrict settings.json to owner only\n```\n\nDefense in depth:\n\n- Add `os.Chmod(configFile, 0o600)` after `TryToPersistChanges`, or on read (as PlanetScale does in `internal/config/config.go` \u2014 they `Stat` the token file and self-heal if `Mode() \u0026^ 0o600` is nonzero). `viper.SetConfigPermissions` applies only on file creation, so an existing wider-mode file is not tightened otherwise.\n- Add `os.Chmod(configPath, 0o700)` after `configdir.MakePath(configPath)` (line 43) to close the equivalent gap on the enclosing directory, which is otherwise created under the default umask.\n\nPatch: https://github.com/tursodatabase/turso-cli/commit/ffb914849216ef5a86353b3fa6cee66f33af3b66\n\n### Workarounds\n\nUntil upgraded, users can tighten the existing files manually:\n\n```sh\n# Linux\nchmod 600 ~/.config/turso/settings.json\nchmod 700 ~/.config/turso\n\n# macOS\nchmod 600 \"$HOME/Library/Application Support/turso/settings.json\"\nchmod 700 \"$HOME/Library/Application Support/turso\"\n```\n\nThis must be repeated after any operation that recreates the file (e.g.\n`turso auth login`) until the patched version is installed.\n\n### Resources\n\n- Patch commit: https://github.com/tursodatabase/turso-cli/commit/ffb914849216ef5a86353b3fa6cee66f33af3b66\n- Viper `configPermissions` default: https://github.com/spf13/viper/blob/v1.21.0/viper.go#L198\n- Viper write path: https://github.com/spf13/viper/blob/v1.21.0/viper.go#L1688\n- CWE-276: https://cwe.mitre.org/data/definitions/276.html\n- CWE-732: https://cwe.mitre.org/data/definitions/732.html",
"id": "GHSA-57f6-pvx8-hwj6",
"modified": "2026-06-26T20:44:39Z",
"published": "2026-06-26T20:44:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tursodatabase/turso-cli/security/advisories/GHSA-57f6-pvx8-hwj6"
},
{
"type": "PACKAGE",
"url": "https://github.com/tursodatabase/turso-cli"
}
],
"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"
}
],
"summary": "turso-cli persists Turso platform JWT with world-readable (0o644) file permissions"
}
GHSA-583C-3965-F379
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2024-04-04 00:30An exploitable Permission Assignment vulnerability exists in the ACEManager EmbeddedAceSet_Task.cgi functionality of Sierra Wireless AirLink ES450 FW 4.9.3. The EmbeddedAceSet_Task.cgi executable is used to change MSCII configuration values within the configuration manager of the AirLink ES450. This binary does not have any restricted configuration settings, so once the MSCIID is discovered, any authenticated user can send configuration changes using the /cgi-bin/Embedded_Ace_Set_Task.cgi endpoint.
{
"affected": [],
"aliases": [
"CVE-2018-4072"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-06T19:29:00Z",
"severity": "HIGH"
},
"details": "An exploitable Permission Assignment vulnerability exists in the ACEManager EmbeddedAceSet_Task.cgi functionality of Sierra Wireless AirLink ES450 FW 4.9.3. The EmbeddedAceSet_Task.cgi executable is used to change MSCII configuration values within the configuration manager of the AirLink ES450. This binary does not have any restricted configuration settings, so once the MSCIID is discovered, any authenticated user can send configuration changes using the /cgi-bin/Embedded_Ace_Set_Task.cgi endpoint.",
"id": "GHSA-583c-3965-f379",
"modified": "2024-04-04T00:30:22Z",
"published": "2022-05-24T16:45:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-4072"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2018-0756"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-583V-XW8H-QW2H
Vulnerability from github – Published: 2023-11-08 18:30 – Updated: 2023-11-08 18:30A local privilege escalation (PE) vulnerability in the Palo Alto Networks Cortex XSOAR engine software running on a Linux operating system enables a local attacker to execute programs with elevated privileges if the attacker has shell access to the engine.
{
"affected": [],
"aliases": [
"CVE-2023-3282"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-08T18:15:07Z",
"severity": "MODERATE"
},
"details": "A local privilege escalation (PE) vulnerability in the Palo Alto Networks Cortex XSOAR engine software running on a Linux operating system enables a local attacker to execute programs with elevated privileges if the attacker has shell access to the engine.",
"id": "GHSA-583v-xw8h-qw2h",
"modified": "2023-11-08T18:30:31Z",
"published": "2023-11-08T18:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3282"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2023-3282"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-584R-323C-J8PC
Vulnerability from github – Published: 2023-06-15 21:30 – Updated: 2024-04-04 04:53Broken access control in the Registration page (/Registration.aspx) of Termenos CWX v8.5.6 allows attackers to access sensitive information.
{
"affected": [],
"aliases": [
"CVE-2023-34797"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-15T21:15:09Z",
"severity": "MODERATE"
},
"details": "Broken access control in the Registration page (/Registration.aspx) of Termenos CWX v8.5.6 allows attackers to access sensitive information.",
"id": "GHSA-584r-323c-j8pc",
"modified": "2024-04-04T04:53:15Z",
"published": "2023-06-15T21:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34797"
},
{
"type": "WEB",
"url": "https://github.com/WhiteBearVN/CWX-Registration-Broken-Access-Control"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-586P-CP79-C7HV
Vulnerability from github – Published: 2023-06-16 09:30 – Updated: 2024-04-04 04:54Vulnerability of undefined permissions in HUAWEI VR screen projection.Successful exploitation of this vulnerability will cause third-party apps to create windows in an arbitrary way, consuming system resources.
{
"affected": [],
"aliases": [
"CVE-2023-34154"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-16T07:15:08Z",
"severity": "HIGH"
},
"details": "Vulnerability of undefined permissions in HUAWEI VR screen projection.Successful exploitation of this vulnerability will cause third-party apps to create windows in an arbitrary way, consuming system resources.",
"id": "GHSA-586p-cp79-c7hv",
"modified": "2024-04-04T04:54:04Z",
"published": "2023-06-16T09:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34154"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202306-0000001560777672"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A: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.