Common Weakness Enumeration
CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
14695 vulnerabilities reference this CWE, most recent first.
GHSA-QF34-295C-26V8
Vulnerability from github – Published: 2026-07-14 20:29 – Updated: 2026-07-14 20:29
VLAI
Summary
Woodpecker: Privilege escalation via unrestricted serviceAccountName in the Kubernetes backend
Details
Impact
A privilege escalation vulnerability affects Woodpecker instances using the Kubernetes backend.
The pipeline option backend_options.kubernetes.serviceAccountName was passed directly to the pod spec without any admin gating.
Who is impacted: any operator running the Kubernetes backend. Any user with Push permission on a connected repository can run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace, gaining that account's RBAC permissions. If a privileged ServiceAccount is reachable in that namespace, this can lead to secret exfiltration (database credentials, API keys, TLS certs) and full cluster takeover.
Patches
https://github.com/woodpecker-ci/woodpecker/pull/6792
Workarounds
Operators who cannot upgrade immediately can mitigate by any of:
- Restrict Push access on repositories connected to the Kubernetes-backed instance to trusted users only.
- Harden the pipeline namespace: ensure no privileged ServiceAccount exists or is bound in
the namespace where pipeline pods run; keep the
defaultServiceAccount minimally privileged. - Disable ServiceAccount token automounting for ServiceAccounts that should not be used by pipelines.
- Enforce an admission policy (e.g. OPA/Gatekeeper, Kyverno, or a ValidatingAdmissionPolicy)
that rejects pipeline pods setting an unexpected
serviceAccountName. - Use a dedicated, isolated namespace per org/instance with no sensitive RBAC bindings.
Resources
- Vulnerable option introduced in commit
609ba481b5e912f59aaae8ca7bc22b44523c5e37 - Affected versions:
v1.0.0throughv3.15.0 - Source:
pipeline/backend/kubernetes/backend_options.go(fieldServiceAccountName),pipeline/backend/kubernetes/pod.go(assigned to pod spec with no gating)
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "go.woodpecker-ci.org/woodpecker/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.16.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/woodpecker-ci/woodpecker"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"last_affected": "1.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "go.woodpecker-ci.org/woodpecker/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.8.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-61549"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-14T20:29:32Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nA privilege escalation vulnerability affects Woodpecker instances using the **Kubernetes backend**.\n\nThe pipeline option `backend_options.kubernetes.serviceAccountName` was passed directly to the pod spec without any admin gating.\n\n**Who is impacted:** any operator running the Kubernetes backend. Any user with **Push** permission on a connected repository can run pipeline pods under an arbitrary ServiceAccount in the pipeline namespace, gaining that account\u0027s RBAC permissions. If a privileged ServiceAccount is reachable in that namespace, this can lead to secret exfiltration (database credentials, API keys, TLS certs) and full cluster takeover.\n\n### Patches\n\nhttps://github.com/woodpecker-ci/woodpecker/pull/6792\n\n### Workarounds\n\nOperators who cannot upgrade immediately can mitigate by any of:\n\n- **Restrict Push access** on repositories connected to the Kubernetes-backed instance to\n trusted users only.\n- **Harden the pipeline namespace**: ensure no privileged ServiceAccount exists or is bound in\n the namespace where pipeline pods run; keep the `default` ServiceAccount minimally privileged.\n- **Disable ServiceAccount token automounting** for ServiceAccounts that should not be used by\n pipelines.\n- **Enforce an admission policy** (e.g. OPA/Gatekeeper, Kyverno, or a ValidatingAdmissionPolicy)\n that rejects pipeline pods setting an unexpected `serviceAccountName`.\n- **Use a dedicated, isolated namespace** per org/instance with no sensitive RBAC bindings.\n\n### Resources\n\n- Vulnerable option introduced in commit `609ba481b5e912f59aaae8ca7bc22b44523c5e37`\n- Affected versions: `v1.0.0` through `v3.15.0`\n- Source: `pipeline/backend/kubernetes/backend_options.go` (field `ServiceAccountName`),\n `pipeline/backend/kubernetes/pod.go` (assigned to pod spec with no gating)",
"id": "GHSA-qf34-295c-26v8",
"modified": "2026-07-14T20:29:32Z",
"published": "2026-07-14T20:29:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/woodpecker-ci/woodpecker/security/advisories/GHSA-qf34-295c-26v8"
},
{
"type": "WEB",
"url": "https://github.com/woodpecker-ci/woodpecker/pull/6792"
},
{
"type": "PACKAGE",
"url": "https://github.com/woodpecker-ci/woodpecker"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Woodpecker: Privilege escalation via unrestricted serviceAccountName in the Kubernetes backend"
}
GHSA-QF42-F5VF-6W99
Vulnerability from github – Published: 2023-09-06 15:30 – Updated: 2024-01-30 23:01
VLAI
Summary
Disabled permissions granted by Jenkins Assembla Auth Plugin
Details
Jenkins Assembla Auth Plugin 1.14 and earlier does not verify that the permissions it grants are enabled, resulting in users with EDIT permissions to be granted Overall/Manage and Overall/SystemRead permissions, even if those permissions are disabled and should not be granted.
Severity
8.8 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:assembla-auth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-41945"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-30T23:01:31Z",
"nvd_published_at": "2023-09-06T13:15:11Z",
"severity": "HIGH"
},
"details": "Jenkins Assembla Auth Plugin 1.14 and earlier does not verify that the permissions it grants are enabled, resulting in users with EDIT permissions to be granted Overall/Manage and Overall/SystemRead permissions, even if those permissions are disabled and should not be granted.",
"id": "GHSA-qf42-f5vf-6w99",
"modified": "2024-01-30T23:01:31Z",
"published": "2023-09-06T15:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41945"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-09-06/#SECURITY-3065"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/09/06/9"
}
],
"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"
}
],
"summary": "Disabled permissions granted by Jenkins Assembla Auth Plugin"
}
GHSA-QF44-4QFP-XRWM
Vulnerability from github – Published: 2024-05-03 09:30 – Updated: 2026-04-28 21:35
VLAI
Details
Missing Authorization vulnerability in SlickRemix Feed Them Social.This issue affects Feed Them Social: from n/a through 4.2.0.
Severity
4.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-24710"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-03T08:15:07Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in SlickRemix Feed Them Social.This issue affects Feed Them Social: from n/a through 4.2.0.",
"id": "GHSA-qf44-4qfp-xrwm",
"modified": "2026-04-28T21:35:02Z",
"published": "2024-05-03T09:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24710"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/feed-them-social/wordpress-feed-them-social-plugin-4-2-0-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QF4P-7GQC-X6JX
Vulnerability from github – Published: 2022-07-28 00:00 – Updated: 2023-10-27 20:16
VLAI
Summary
Jenkins Compuware Topaz Utilities Plugin is missing authorization
Details
Jenkins Compuware Topaz Utilities Plugin 1.0.8 and earlier does not perform permission checks in several HTTP endpoints.
This allows attackers with Overall/Read permission to enumerate hosts and ports of Compuware configurations and credentials IDs of credentials stored in Jenkins. Those credentials IDs can be used as part of an attack to capture the credentials using another vulnerability.
Compuware Topaz Utilities Plugin 1.0.9 requires the appropriate permissions to enumerate hosts and ports of Compuware configurations and credentials IDs.
Severity
4.3 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.8"
},
"package": {
"ecosystem": "Maven",
"name": "com.compuware.jenkins:compuware-topaz-utilities"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-36895"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2022-08-10T21:14:01Z",
"nvd_published_at": "2022-07-27T15:15:00Z",
"severity": "MODERATE"
},
"details": "Jenkins Compuware Topaz Utilities Plugin 1.0.8 and earlier does not perform permission checks in several HTTP endpoints.\n\nThis allows attackers with Overall/Read permission to enumerate hosts and ports of Compuware configurations and credentials IDs of credentials stored in Jenkins. Those credentials IDs can be used as part of an attack to capture the credentials using another vulnerability.\n\nCompuware Topaz Utilities Plugin 1.0.9 requires the appropriate permissions to enumerate hosts and ports of Compuware configurations and credentials IDs.",
"id": "GHSA-qf4p-7gqc-x6jx",
"modified": "2023-10-27T20:16:35Z",
"published": "2022-07-28T00:00:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36895"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/compuware-topaz-utilities-plugin/commit/a79f95c7d32ad6a2e161159fa77f371705f3b20d"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-07-27/#SECURITY-2619"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/07/27/1"
}
],
"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"
}
],
"summary": "Jenkins Compuware Topaz Utilities Plugin is missing authorization"
}
GHSA-QF5W-6PPH-H289
Vulnerability from github – Published: 2026-01-08 12:30 – Updated: 2026-01-20 15:33
VLAI
Details
Missing Authorization vulnerability in G5Theme Zorka zorka allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Zorka: from n/a through <= 1.5.7.
Severity
5.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-0676"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-08T10:15:55Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in G5Theme Zorka zorka allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Zorka: from n/a through \u003c= 1.5.7.",
"id": "GHSA-qf5w-6pph-h289",
"modified": "2026-01-20T15:33:11Z",
"published": "2026-01-08T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0676"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Theme/zorka/vulnerability/wordpress-zorka-theme-1-5-7-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Theme/zorka/vulnerability/wordpress-zorka-theme-1-5-7-broken-access-control-vulnerability?_s_id=cve"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-QF8P-5G4M-C6XM
Vulnerability from github – Published: 2024-11-01 15:31 – Updated: 2024-11-01 15:31
VLAI
Details
Missing Authorization vulnerability in bPlugins LLC Flash & HTML5 Video allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Flash & HTML5 Video: from n/a through 2.5.30.
Severity
4.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-43296"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-01T15:15:45Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in bPlugins LLC Flash \u0026 HTML5 Video allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Flash \u0026 HTML5 Video: from n/a through 2.5.30.",
"id": "GHSA-qf8p-5g4m-c6xm",
"modified": "2024-11-01T15:31:59Z",
"published": "2024-11-01T15:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43296"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/html5-video-player/wordpress-html5-video-player-plugin-2-5-30-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QF9M-88XV-JVJP
Vulnerability from github – Published: 2024-08-21 06:32 – Updated: 2026-04-08 18:33
VLAI
Details
The Smart Online Order for Clover plugin for WordPress is vulnerable to unauthorized loss of data due to a missing capability check on the 'moo_deactivateAndClean' function in all versions up to, and including, 1.5.6. This makes it possible for unauthenticated attackers to deactivate the plugin and drop all plugin tables from the database.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-7032"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T06:15:10Z",
"severity": "MODERATE"
},
"details": "The Smart Online Order for Clover plugin for WordPress is vulnerable to unauthorized loss of data due to a missing capability check on the \u0027moo_deactivateAndClean\u0027 function in all versions up to, and including, 1.5.6. This makes it possible for unauthenticated attackers to deactivate the plugin and drop all plugin tables from the database.",
"id": "GHSA-qf9m-88xv-jvjp",
"modified": "2026-04-08T18:33:35Z",
"published": "2024-08-21T06:32:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7032"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/clover-online-orders/trunk/includes/moo-OnlineOrders-deactivator.php#L29"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/clover-online-orders/trunk/moo_OnlineOrders.php#L183"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3142846"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/9a6b05b1-c649-4b72-b884-11fb83ec77f2?source=cve"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-QFF7-Q5FM-8P76
Vulnerability from github – Published: 2026-05-04 21:19 – Updated: 2026-05-04 21:19
VLAI
Summary
AzuraCast has Missing Permissions Check on Media File Download, Allowing Cross-Station Data Exfiltration
Details
Summary
The GET /api/station/{station_id}/file/{id}/play endpoint, handled by PlayAction, is missing the Middleware\Permissions check that protects all sibling routes in the same /file/{id} route group. Any authenticated user can download media files from any station, regardless of whether they have permissions on that station. In multi-tenant deployments, this enables cross-station media exfiltration.
Details
In backend/config/routes/api_station.php, the /file/{id} route group (lines 407-429) defines four endpoints:
// Line 407-429
$group->group(
'/file/{id}',
function (RouteCollectorProxy $group) {
// GET /file/{id} — has Permissions check ✓
$group->get('', ...)->add(new Middleware\Permissions(StationPermissions::Media, true));
// PUT /file/{id} — has Permissions check ✓
$group->put('', ...)->add(new Middleware\Permissions(StationPermissions::Media, true));
// DELETE /file/{id} — has Permissions check ✓
$group->delete('', ...)->add(new Middleware\Permissions(StationPermissions::DeleteMedia, true));
// GET /file/{id}/play — NO Permissions check ✗
$group->get('/play', Controller\Api\Stations\Files\PlayAction::class)
->setName('api:stations:files:play');
}
);
The middleware chain for the /play endpoint is: GetStation → RequireStation → RequireLogin → StationSupportsFeature(Media) → PlayAction. The RequireLogin middleware (backend/src/Middleware/RequireLogin.php) only verifies a valid session/API key exists — it does not check station-level permissions.
The controller at backend/src/Controller/Api/Stations/Files/PlayAction.php:84 calls $this->mediaRepo->requireForStation($id, $station), which verifies the media belongs to the station but performs no authorization check. The findForStation method (StationMediaRepository.php:46-66) accepts both auto-increment integer IDs and unique IDs, making enumeration trivial via sequential integers.
This is notably similar to the regression fixed in commit 7fbc7dd (2026-02-26), which restored a missing group-level Permissions middleware on the adjacent /files group. The /play route was missed in that fix.
PoC
# Step 1: Create two stations (Station A and Station B) in a multi-tenant AzuraCast instance.
# Upload media files to Station B.
# Step 2: Create a user with permissions ONLY on Station A. Generate an API key for this user.
API_KEY="user-with-only-station-a-access"
# Step 3: Enumerate and download media from Station B (station_id=2) using sequential IDs
# This should return 403 Forbidden, but instead returns the file content
curl -H "X-API-Key: $API_KEY" https://target/api/station/2/file/1/play -o stolen1.mp3
# HTTP 200 OK — file downloaded successfully
curl -H "X-API-Key: $API_KEY" https://target/api/station/2/file/2/play -o stolen2.mp3
# HTTP 200 OK — file downloaded successfully
# Step 4: Verify the same user is correctly blocked on other endpoints in the same group
curl -H "X-API-Key: $API_KEY" https://target/api/station/2/file/1
# HTTP 403 Forbidden — permission check works here
Impact
- Any authenticated user can download the full media library of any station in the instance, regardless of their assigned permissions.
- In multi-tenant deployments (e.g., hosting providers running multiple radio stations), a user of Station A can exfiltrate all copyrighted audio content from Station B.
- Media IDs use auto-increment integers (
HasAutoIncrementIdtrait onStationMedia), enabling trivial enumeration of all media files. - The confidentiality impact is High: full media file contents (MP3, FLAC, etc.) are exposed.
Recommended Fix
Add the Permissions middleware to the /play route, matching the pattern used by the adjacent routes:
// backend/config/routes/api_station.php, line 426-427
// Before:
$group->get('/play', Controller\Api\Stations\Files\PlayAction::class)
->setName('api:stations:files:play');
// After:
$group->get('/play', Controller\Api\Stations\Files\PlayAction::class)
->setName('api:stations:files:play')
->add(new Middleware\Permissions(StationPermissions::Media, true));
Severity
6.5 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.5"
},
"package": {
"ecosystem": "Packagist",
"name": "azuracast/azuracast"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-04T21:19:24Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `GET /api/station/{station_id}/file/{id}/play` endpoint, handled by `PlayAction`, is missing the `Middleware\\Permissions` check that protects all sibling routes in the same `/file/{id}` route group. Any authenticated user can download media files from any station, regardless of whether they have permissions on that station. In multi-tenant deployments, this enables cross-station media exfiltration.\n\n## Details\n\nIn `backend/config/routes/api_station.php`, the `/file/{id}` route group (lines 407-429) defines four endpoints:\n\n```php\n// Line 407-429\n$group-\u003egroup(\n \u0027/file/{id}\u0027,\n function (RouteCollectorProxy $group) {\n // GET /file/{id} \u2014 has Permissions check \u2713\n $group-\u003eget(\u0027\u0027, ...)-\u003eadd(new Middleware\\Permissions(StationPermissions::Media, true));\n\n // PUT /file/{id} \u2014 has Permissions check \u2713\n $group-\u003eput(\u0027\u0027, ...)-\u003eadd(new Middleware\\Permissions(StationPermissions::Media, true));\n\n // DELETE /file/{id} \u2014 has Permissions check \u2713\n $group-\u003edelete(\u0027\u0027, ...)-\u003eadd(new Middleware\\Permissions(StationPermissions::DeleteMedia, true));\n\n // GET /file/{id}/play \u2014 NO Permissions check \u2717\n $group-\u003eget(\u0027/play\u0027, Controller\\Api\\Stations\\Files\\PlayAction::class)\n -\u003esetName(\u0027api:stations:files:play\u0027);\n }\n);\n```\n\nThe middleware chain for the `/play` endpoint is: `GetStation \u2192 RequireStation \u2192 RequireLogin \u2192 StationSupportsFeature(Media) \u2192 PlayAction`. The `RequireLogin` middleware (`backend/src/Middleware/RequireLogin.php`) only verifies a valid session/API key exists \u2014 it does not check station-level permissions.\n\nThe controller at `backend/src/Controller/Api/Stations/Files/PlayAction.php:84` calls `$this-\u003emediaRepo-\u003erequireForStation($id, $station)`, which verifies the media belongs to the station but performs no authorization check. The `findForStation` method (`StationMediaRepository.php:46-66`) accepts both auto-increment integer IDs and unique IDs, making enumeration trivial via sequential integers.\n\nThis is notably similar to the regression fixed in commit `7fbc7dd` (2026-02-26), which restored a missing group-level `Permissions` middleware on the adjacent `/files` group. The `/play` route was missed in that fix.\n\n## PoC\n\n```bash\n# Step 1: Create two stations (Station A and Station B) in a multi-tenant AzuraCast instance.\n# Upload media files to Station B.\n\n# Step 2: Create a user with permissions ONLY on Station A. Generate an API key for this user.\nAPI_KEY=\"user-with-only-station-a-access\"\n\n# Step 3: Enumerate and download media from Station B (station_id=2) using sequential IDs\n# This should return 403 Forbidden, but instead returns the file content\ncurl -H \"X-API-Key: $API_KEY\" https://target/api/station/2/file/1/play -o stolen1.mp3\n# HTTP 200 OK \u2014 file downloaded successfully\n\ncurl -H \"X-API-Key: $API_KEY\" https://target/api/station/2/file/2/play -o stolen2.mp3\n# HTTP 200 OK \u2014 file downloaded successfully\n\n# Step 4: Verify the same user is correctly blocked on other endpoints in the same group\ncurl -H \"X-API-Key: $API_KEY\" https://target/api/station/2/file/1\n# HTTP 403 Forbidden \u2014 permission check works here\n```\n\n## Impact\n\n- Any authenticated user can download the full media library of any station in the instance, regardless of their assigned permissions.\n- In multi-tenant deployments (e.g., hosting providers running multiple radio stations), a user of Station A can exfiltrate all copyrighted audio content from Station B.\n- Media IDs use auto-increment integers (`HasAutoIncrementId` trait on `StationMedia`), enabling trivial enumeration of all media files.\n- The confidentiality impact is High: full media file contents (MP3, FLAC, etc.) are exposed.\n\n## Recommended Fix\n\nAdd the `Permissions` middleware to the `/play` route, matching the pattern used by the adjacent routes:\n\n```php\n// backend/config/routes/api_station.php, line 426-427\n// Before:\n$group-\u003eget(\u0027/play\u0027, Controller\\Api\\Stations\\Files\\PlayAction::class)\n -\u003esetName(\u0027api:stations:files:play\u0027);\n\n// After:\n$group-\u003eget(\u0027/play\u0027, Controller\\Api\\Stations\\Files\\PlayAction::class)\n -\u003esetName(\u0027api:stations:files:play\u0027)\n -\u003eadd(new Middleware\\Permissions(StationPermissions::Media, true));\n```",
"id": "GHSA-qff7-q5fm-8p76",
"modified": "2026-05-04T21:19:24Z",
"published": "2026-05-04T21:19:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/AzuraCast/AzuraCast/security/advisories/GHSA-qff7-q5fm-8p76"
},
{
"type": "WEB",
"url": "https://github.com/AzuraCast/AzuraCast/commit/ba92dc3f0ea15a9c0ba0f4557d99a9a26004108f"
},
{
"type": "PACKAGE",
"url": "https://github.com/AzuraCast/AzuraCast"
}
],
"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": "AzuraCast has Missing Permissions Check on Media File Download, Allowing Cross-Station Data Exfiltration"
}
GHSA-QFH3-P8JM-V9FX
Vulnerability from github – Published: 2026-05-12 12:32 – Updated: 2026-05-12 12:32
VLAI
Details
Missing Authorization vulnerability in Broadstreet Broadstreet Ads broadstreet allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Broadstreet Ads: from n/a through <= 1.52.2.
Severity
5.4 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-45210"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-12T11:16:20Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Broadstreet Broadstreet Ads broadstreet allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Broadstreet Ads: from n/a through \u003c= 1.52.2.",
"id": "GHSA-qfh3-p8jm-v9fx",
"modified": "2026-05-12T12:32:16Z",
"published": "2026-05-12T12:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45210"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/broadstreet/vulnerability/wordpress-broadstreet-ads-plugin-1-52-2-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-QFHP-VG9X-9692
Vulnerability from github – Published: 2026-01-14 06:30 – Updated: 2026-01-14 06:30
VLAI
Details
The Responsive Accordion Slider plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the 'resp_accordion_silder_save_images' function in all versions up to, and including, 1.2.2. This makes it possible for authenticated attackers, with Contributor-level access and above, to modify any slider's image metadata including titles, descriptions, alt text, and links.
Severity
4.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-0635"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-14T06:15:55Z",
"severity": "MODERATE"
},
"details": "The Responsive Accordion Slider plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the \u0027resp_accordion_silder_save_images\u0027 function in all versions up to, and including, 1.2.2. This makes it possible for authenticated attackers, with Contributor-level access and above, to modify any slider\u0027s image metadata including titles, descriptions, alt text, and links.",
"id": "GHSA-qfhp-vg9x-9692",
"modified": "2026-01-14T06:30:24Z",
"published": "2026-01-14T06:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0635"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/responsive-accordion-slider/tags/1.2.2/includes/admin/class-ras-admin.php#L101"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/55cfb2c6-ca3f-45b7-8cd9-a5a1c3783ae0?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Architecture and Design
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Architecture and Design
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration
Installation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.