CWE-862
Weakness 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.
Dimensions
- Behavior-Property: Missing
- Behavior-Type: Authorization
Mapping guidance
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit
Relationships and members
Modes of introduction
OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.
A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.
Detection methods
Automated Static Analysis
Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.
Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.
Effectiveness: Limited
Automated Dynamic Analysis
Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic.
Manual Analysis
This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.
Effectiveness: Moderate
These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.
Manual Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Web Application Scanner
Web Services Scanner
Database Scanners
Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Host Application Interface Scanner
Fuzz Tester
Framework-based Fuzzer
Effectiveness: SOAR Partial
Manual Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)
Effectiveness: SOAR Partial
Automated Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer
Effectiveness: SOAR Partial
Architecture or Design Review
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction
Effectiveness: High
Notes
Terminology
Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
Content history
Suggested mappings to ISA/IEC 62443.
Provided diagram to improve CWE usability
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
updated Potential_Mitigations, References, Relationships
updated Demonstrative_Examples, Observed_Examples, References, Relationships
updated Potential_Mitigations
updated Relationships
updated Detection_Factors
updated Relationships
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
updated References
updated Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms, Observed_Examples
updated Observed_Examples, Related_Attack_Patterns, Relationships
updated Relationships
updated Relationships
updated Observed_Examples
updated Description, Potential_Mitigations
updated References, Relationships, Taxonomy_Mappings
updated Mapping_Notes, Relationships, Taxonomy_Mappings
updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References
updated Applicable_Platforms, Relationships, Weakness_Ordinalities
updated Applicable_Platforms, Observed_Examples, Relationships
updated Applicable_Platforms, Dimensions, References, Relationships, Taxonomy_Mappings
19866 vulnerabilities reference this CWE, most recent first.
GHSA-8MMG-G9GW-84MH
Vulnerability from github – Published: 2026-10-05 03:30 – Updated: 2026-10-05 12:31In aidl, there is a possible escalation of privilege due to a missing permission check. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS11185216; Issue ID: MSV-9039.
{
"affected": [],
"aliases": [
"CVE-2026-20535"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-05T02:16:52Z",
"severity": "MODERATE"
},
"details": "In aidl, there is a possible escalation of privilege due to a missing permission check. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS11185216; Issue ID: MSV-9039.",
"id": "GHSA-8mmg-g9gw-84mh",
"modified": "2026-10-05T12:31:23Z",
"published": "2026-10-05T03:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20535"
},
{
"type": "WEB",
"url": "https://www.mediatek.com/product-security-bulletin/October-2026"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8MPJ-5QHW-H3QV
Vulnerability from github – Published: 2026-08-05 09:31 – Updated: 2026-08-05 09:31The AI Chatbot & Workflow Automation by AIWU plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.4.6. This is due to the getCurrentTaskResults() method in modules/workspace/controller.php being accessible without authentication or authorization checks. The method is not included in the workspace controller's getNoncedMethods() array, the base getPermissions() returns an empty array, and all AJAX actions are registered with wp_ajax_nopriv_ hooks (classes/frame.php:282). When tasks are created via features like the Bulk Post Generator, the task parameters — including the OpenAI API key in plaintext, AI prompts, keywords, and full AI model configuration — are stored in the database and returned in the JSON response. This makes it possible for unauthenticated attackers to enumerate sequential task IDs and retrieve sensitive configuration data including API keys.
{
"affected": [],
"aliases": [
"CVE-2026-6639"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-05T08:16:41Z",
"severity": "HIGH"
},
"details": "The AI Chatbot \u0026 Workflow Automation by AIWU plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.4.6. This is due to the `getCurrentTaskResults()` method in `modules/workspace/controller.php` being accessible without authentication or authorization checks. The method is not included in the workspace controller\u0027s `getNoncedMethods()` array, the base `getPermissions()` returns an empty array, and all AJAX actions are registered with `wp_ajax_nopriv_` hooks (`classes/frame.php:282`). When tasks are created via features like the Bulk Post Generator, the task parameters \u2014 including the OpenAI API key in plaintext, AI prompts, keywords, and full AI model configuration \u2014 are stored in the database and returned in the JSON response. This makes it possible for unauthenticated attackers to enumerate sequential task IDs and retrieve sensitive configuration data including API keys.",
"id": "GHSA-8mpj-5qhw-h3qv",
"modified": "2026-08-05T09:31:18Z",
"published": "2026-08-05T09:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6639"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/ai-copilot-content-generator/tags/1.4.6/classes/frame.php#L282"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/ai-copilot-content-generator/tags/1.4.6/modules/workspace/controller.php#L83"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/ai-copilot-content-generator/tags/1.4.6/modules/workspace/models/tasks.php#L106"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?new=3528734%40ai-copilot-content-generator%2Ftrunk\u0026old=3525474%40ai-copilot-content-generator%2Ftrunk"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/ai-copilot-content-generator"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/247b1921-70a6-4e65-819a-2895bc395e9f?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8MPV-23RW-JFJX
Vulnerability from github – Published: 2026-10-21 06:31 – Updated: 2026-10-21 12:31The Wava Payment Plugin WordPress plugin before 0.3.10 does not verify the authenticity of incoming payment-provider notifications, nor restrict who may send them, allowing unauthenticated attackers to change the status of any WooCommerce order in the store, including marking an unpaid order as paid and completed, and cancelling other customers' orders.
In versions up to 0.3.7 the response additionally returns the affected order's billing details, disclosing customer names, addresses, email addresses and phone numbers to the same unauthenticated caller.
{
"affected": [],
"aliases": [
"CVE-2026-87837"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-21T06:16:50Z",
"severity": "MODERATE"
},
"details": "The Wava Payment Plugin WordPress plugin before 0.3.10 does not verify the authenticity of incoming payment-provider notifications, nor restrict who may send them, allowing unauthenticated attackers to change the status of any WooCommerce order in the store, including marking an unpaid order as paid and completed, and cancelling other customers\u0027 orders.\n\nIn versions up to 0.3.7 the response additionally returns the affected order\u0027s billing details, disclosing customer names, addresses, email addresses and phone numbers to the same unauthenticated caller.",
"id": "GHSA-8mpv-23rw-jfjx",
"modified": "2026-10-21T12:31:06Z",
"published": "2026-10-21T06:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87837"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/76da1b69-aa79-4e9e-a97a-bbaefdeb65fe"
}
],
"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-8MQ2-FRFG-QR49
Vulnerability from github – Published: 2026-03-25 18:31 – Updated: 2026-03-27 15:30Missing Authorization vulnerability in CoderPress Commerce Coinbase For WooCommerce commerce-coinbase-for-woocommerce allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Commerce Coinbase For WooCommerce: from n/a through <= 1.6.6.
{
"affected": [],
"aliases": [
"CVE-2026-25396"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T17:16:49Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in CoderPress Commerce Coinbase For WooCommerce commerce-coinbase-for-woocommerce allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Commerce Coinbase For WooCommerce: from n/a through \u003c= 1.6.6.",
"id": "GHSA-8mq2-frfg-qr49",
"modified": "2026-03-27T15:30:25Z",
"published": "2026-03-25T18:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25396"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/commerce-coinbase-for-woocommerce/vulnerability/wordpress-commerce-coinbase-for-woocommerce-plugin-1-6-6-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:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8MQ9-5FW2-5RM4
Vulnerability from github – Published: 2026-08-19 21:56 – Updated: 2026-08-21 18:31Summary
The production media handler shipped by next-tinacms-s3 (createMediaHandler in packages/next-tinacms-s3/src/handlers.ts) accepts an attacker-chosen ?key= query parameter and returns an AWS-signed PutObject URL whose Key is that value, with no check that the key falls under the operator's configured mediaRoot. The same handler's DELETE branch reads objectKey = (req.query.media as string[])[1] and dispatches a DeleteObjectCommand for that exact key, again unbounded by mediaRoot. Any caller that passes the operator-supplied authorized() predicate — i.e. any logged-in CMS editor in a typical TinaCloud / self-hosted deployment — therefore has write and delete authority over the entire S3 bucket the IAM key can reach, even though the package documents mediaRoot as the place where editors are scoped. The same shape is present in next-tinacms-dos, next-tinacms-azure, and next-tinacms-cloudinary, so a single design mistake spans every first-party production media backend.
- Project: TinaCMS — first-party production media adapters (consumed by self-hosted Next.js sites and TinaCloud-backed deployments).
- Source reviewed:
tinacms/tinacms@main(b56dad4). - Deployed artefact validated:
next-tinacms-s3@21.0.3handler logic, exercised against@aws-sdk/client-s3@3.665.xviaaws-sdk-client-mock@4.1.0(the AWS SDK signs the URL identically whether the bucket is real or mocked). - Affected file(s):
packages/next-tinacms-s3/src/handlers.ts:67-90—GET ?key=returns presignedPutObjectCommandURL with attacker-chosenKey.packages/next-tinacms-s3/src/handlers.ts:199-223—DELETEreads[, objectKey] = mediaand issuesDeleteObjectCommandagainst attacker-chosenKey.packages/next-tinacms-dos/src/handlers.ts:79-152and:249-278— same write/delete pattern, plus a server-side upload that builds the key withpath.join(mediaRoot, prefix + filename)over attacker-controlleddirectoryandfilename.packages/next-tinacms-azure/src/handlers.ts:44-95—uploadMediawritespath.join(directory, filename)with both fields attacker-controlled (nomediaRootconfigured at all);deleteAssetdeletes any blob in the container.packages/next-tinacms-cloudinary/src/handlers.ts:193-204—cloudinary.uploader.destroy(public_id)over attacker-chosenpublic_id.- CWE: CWE-639 — Authorization Bypass Through User-Controlled Key. Adjacent: CWE-284 (Improper Access Control), CWE-862 (Missing Authorization on the per-key authority check).
- OWASP 2021: A01:2021 — Broken Access Control (the operator's intended
mediaRootboundary is enforced only on listing, not on writes or deletes). Secondary: A04:2021 — Insecure Design (every adapter independently re-implements the same broken pattern).
Vulnerable code
packages/next-tinacms-s3/src/handlers.ts:39-98:
export const createMediaHandler = (config: S3Config, options?: S3Options) => {
const client = new S3Client(config.config);
const bucket = config.bucket;
let mediaRoot = config.mediaRoot || ''; // (1)
if (mediaRoot) { /* normalise to "media/" form */ }
return async (req: NextApiRequest, res: NextApiResponse) => {
const isAuthorized = await config.authorized(req, res);
if (!isAuthorized) {
res.status(401).json({ message: 'sorry this user is unauthorized' });
return;
}
switch (req.method) {
case 'GET':
if (req.query.key) {
const expiresIn: number =
(req.query.expiresIn && Number(req.query.expiresIn)) || 3600; // (2)
const s3_key = req.query.key
? Array.isArray(req.query.key) ? req.query.key[0] : req.query.key
: null;
if (!s3_key) return res.status(400).json({ message: 'key is required' });
if (await keyExists(client, bucket, s3_key)) {
return res.status(400).json({ message: 'key already exists' }); // (3)
}
const signedUrl = await getUploadUrl(bucket, s3_key, expiresIn, client); // (4)
return res.json({ signedUrl, src: cdnUrl + s3_key });
}
return listMedia(req, res, client, bucket, mediaRoot, cdnUrl); // (5)
case 'DELETE':
return deleteAsset(req, res, client, bucket); // (6)
packages/next-tinacms-s3/src/handlers.ts:199-223:
async function deleteAsset(req, res, client, bucket) {
const { media } = req.query;
const [, objectKey] = media as string[]; // (7)
const params: DeleteObjectCommandInput = { Bucket: bucket, Key: objectKey };
const command = new DeleteObjectCommand(params);
...
}
At (1) the operator configures mediaRoot (e.g. "media/"), and the package's README documents this as the directory the IAM key is scoped to. At (4) the handler signs a PutObjectCommand with Key: s3_key taken verbatim from req.query.key. Nothing between (1) and (4) verifies that s3_key starts with mediaRoot, so any path the IAM key can reach is fair game. The only filter is the keyExists check at (3), which prevents overwrite of an existing object but not creation of arbitrary new ones (and not overwrite of objects the IAM key cannot HeadObject). At (2) the validity window of the produced URL is also attacker-controlled, capped only by AWS SigV4's 7-day hard limit. At (5) the list path does prefix-join mediaRoot (Prefix: mediaRoot ? path.join(mediaRoot, prefix) : prefix), demonstrating that the boundary was understood to exist — it just isn't enforced on writes. At (6) + (7) delete extracts the second URL segment into objectKey with no prefix check, so DELETE /api/s3/media/x/anything-in-the-bucket is a valid arbitrary-key delete primitive.
For contrast, the same package's listMedia (line 139) does write Prefix: mediaRoot ? path.join(mediaRoot, prefix) : prefix, and stripMediaRoot (line 100) exists explicitly to peel mediaRoot off keys returned to the client — so the codebase models mediaRoot as a security boundary on the read side. The write and delete sides simply forgot to apply it.
The same misalignment is duplicated in three sibling packages:
packages/next-tinacms-dos/src/handlers.ts:115-125— upload buildsKey: mediaRoot ? path.join(mediaRoot, prefix + filename) : prefix + filenameover attacker-controlledprefix(fromreq.body.directory) andfilename(frommulter'sfile.originalname);path.joincollapses..segments, so adirectoryof../..plus a chosenfilenamelands at any key in the bucket. Lines 249-278 reproduce the S3 delete-by-second-segment pattern.packages/next-tinacms-azure/src/handlers.ts:44-95—uploadMediawrites a blob atpath.join(directory, filename)with both values straight out offormData.next-tinacms-azurehas nomediaRootconfig at all (AzureBlobStorageConfiginsrc/types.ts), so the entire container is writable / deletable by any authorized user.packages/next-tinacms-cloudinary/src/handlers.ts:193-204—deleteAssetcallscloudinary.uploader.destroy(public_id)over the attacker-chosen second segment, deleting any asset in the cloud. The same handler'slistMedia(line 110) interpolatesmediaListOptions.directorydirectly into a Cloudinary search-expression DSL string (folder="${directory}"), giving an authorized user full search-expression injection — out of scope for this finding but worth a separate report.
Reproduction (validated locally)
Environment: Node 22, @aws-sdk/client-s3@3.665.0, @aws-sdk/s3-request-presigner@3.665.0, aws-sdk-client-mock@4.1.0. The harness vendors createMediaHandler byte-for-byte from packages/next-tinacms-s3/src/handlers.ts and runs it against a mocked S3Client. The AWS SDK signs the URL identically whether the bucket exists — the resulting URL is the same one a real S3 deployment would hand back to the editor's browser, so it would PUT against a real bucket without further help.
PoC layout under /Users/admin/joplin_research/tinacms-s3-poc/:
package.json (deps only)
handler-vendored.mjs (verbatim copy of createMediaHandler, types stripped)
poc.mjs (four exhibits exercising the handler)
Handler is configured the way the package's README documents:
const handler = createMediaHandler({
config: { region: 'us-east-1', credentials: { accessKeyId: '…', secretAccessKey: '…' } },
bucket: 'editor-media-bucket',
mediaRoot: 'media', // editors are "scoped to media/"
authorized: async () => true, // typical wiring: TinaCloud verified user
});
Run:
$ cd /Users/admin/tinacms-s3-poc && node poc.mjs
--- Exhibit A: presigned PUT URL for arbitrary bucket key ---
HTTP status : 200
signedUrl : https://editor-media-bucket.s3.us-east-1.amazonaws.com/index.html?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=AKIAFA...
src : https://editor-media-bucket.s3.us-east-1.amazonaws.com/index.html
signed Key : /index.html
RESULT : BYPASS (signed URL writes outside media/)
--- Exhibit B: cross-tenant overwrite via attacker-chosen key ---
signed Key : /tenant-victim/posts/announcement.mdx
RESULT : BYPASS (cross-tenant write primitive granted)
--- Exhibit C: arbitrary-key DELETE via [...media] route ---
HTTP status : 200
S3 Bucket : editor-media-bucket
S3 Key : tenant-victim/posts/announcement.mdx
RESULT : BYPASS (arbitrary-key DELETE granted)
--- Exhibit D: attacker-controlled ?expiresIn ---
X-Amz-Expires: 604800 sec
RESULT : BYPASS (URL valid far longer than the 1h default)
Verification, in detail:
-
Exhibit A —
GET /api/s3/media?key=index.html.mediaRoot=media/is configured but never consulted on the write path. The handler hands back a SigV4 URL whose path is/index.html. PUT'ing any body to that URL would create the bucket-root objectindex.htmlagainst the operator's IAM credentials. For a deployment that fronts the bucket with CloudFront / S3-website hosting, this is a one-shot site-defacement primitive (and, for any CSP that trusts the bucket, a one-shot stored-XSS primitive against the published site). -
Exhibit B — same primitive, attacker-chosen key
tenant-victim/posts/announcement.mdx. In the multi-tenant TinaCloud / TinaCMS Cloud deployment shape (one bucket shared across tenants, each tenant assigned amediaRoot/<tenant>/prefix), a Tenant A editor receives a presigned PUT URL for any Tenant B key. Cross-tenant content tampering with no further bug needed. -
Exhibit C —
DELETE /api/s3/media/anything-here-is-ignored/tenant-victim%2Fposts%2Fannouncement.mdx. The handler reads the catch-all asreq.query.media = ['anything-here-is-ignored', 'tenant-victim/posts/announcement.mdx'], destructures toobjectKey = media[1], dispatchesDeleteObjectCommand({ Bucket: 'editor-media-bucket', Key: 'tenant-victim/posts/announcement.mdx' }). The mock confirms the captured command'sKeyis the attacker-supplied string. Real S3 will honour the same call. (The mock-captured call confirms the handler's behaviour; the real S3 call requires onlys3:DeleteObjecton the bucket, which the package'sREADMEinstructs operators to grant.) -
Exhibit D —
?expiresIn=604800(7 days, the SigV4 ceiling). The handler accepts it, the resultingX-Amz-Expires=604800. Combined with Exhibit A, an attacker who briefly compromises a CMS session (e.g. via a stolen idle browser session or the dev-server CSRF write described in finding 06) can mint a long-lived offline write primitive — usable for a week with no further interaction with the CMS.
The four exhibits together: cross-mediaRoot write, cross-tenant write, arbitrary-key delete, and long-lived signed-URL minting.
Impact
- Cross-tenant / cross-mediaRoot write. In any deployment where the bucket holds anything other than this one editor's
mediaRoot(multi-tenant TinaCloud, shared corporate bucket, bucket-backed static site), an authorized editor obtains write authority over every key the IAM credential can reach. Concretely: defacement of a static site fronted by the bucket; cross-tenant content tampering; replacement of*.html,*.js,*.jsonassets that downstream consumers trust. (Exhibits A, B;handlers.ts:67-90.) - Stored XSS via uploaded HTML. S3 returns objects with the
Content-Typethe upload supplies. The presignedPutObjectCommandURL carries noContent-Typeconstraint — the attacker'sPUTchooses it. An editor can therefore write an HTML / SVG / JS payload to the bucket-root, and any CDN or origin that serves bucket objects directly to an authenticated SaaS surface inherits stored XSS in that origin. - Arbitrary-key delete (data destruction). Through
[...media]the handler treats the second URL segment as a free-form object key. An editor can wipe any object the IAM key cans3:DeleteObject, including non-media artefacts like deployment manifests, backups, or other tenants' files. (Exhibit C;handlers.ts:199-223.) - Bucket-policy implications. The
README(lines 38-90) tells operators to grant the IAM keys3:PutObject,s3:PutObjectAcl,s3:DeleteObject, ands3:ListBucketon the whole bucket. The README implies the application code constrains the editor's actions tomediaRoot. Because the application code does not, every operator who follows the README has — without realising — granted every CMS editor full write/delete on the whole bucket. - Long-lived offline write primitive.
expiresInis attacker-controlled and not capped by the handler. A single GET request mints a URL valid for up to 7 days (AWS SigV4 ceiling). An attacker who briefly compromises a CMS session can stash one such URL and continue writing arbitrary objects long after the session is revoked. (Exhibit D.) - Same-shape exposure on every other first-party media adapter.
next-tinacms-dos(DigitalOcean Spaces, S3-compatible),next-tinacms-azure(Blob Storage), andnext-tinacms-cloudinary(Cloudinary) all duplicate the broken pattern. Azure has no mediaRoot config at all, so the boundary thatnext-tinacms-s3advertises but doesn't enforce isn't even nominally present innext-tinacms-azure.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "next-tinacms-s3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "23.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next-tinacms-dos"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "23.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next-tinacms-azure"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next-tinacms-cloudinary"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "26.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59992"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-19T21:56:30Z",
"nvd_published_at": "2026-08-19T22:16:40Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe production media handler shipped by `next-tinacms-s3` (`createMediaHandler` in `packages/next-tinacms-s3/src/handlers.ts`) accepts an attacker-chosen `?key=` query parameter and returns an AWS-signed `PutObject` URL whose `Key` is that value, with no check that the key falls under the operator\u0027s configured `mediaRoot`. The same handler\u0027s `DELETE` branch reads `objectKey = (req.query.media as string[])[1]` and dispatches a `DeleteObjectCommand` for that exact key, again unbounded by `mediaRoot`. Any caller that passes the operator-supplied `authorized()` predicate \u2014 i.e. any logged-in CMS editor in a typical TinaCloud / self-hosted deployment \u2014 therefore has write and delete authority over the *entire* S3 bucket the IAM key can reach, even though the package documents `mediaRoot` as the place where editors are scoped. The same shape is present in `next-tinacms-dos`, `next-tinacms-azure`, and `next-tinacms-cloudinary`, so a single design mistake spans every first-party production media backend.\n\n* Project: TinaCMS \u2014 first-party production media adapters (consumed by self-hosted Next.js sites and TinaCloud-backed deployments).\n* Source reviewed: `tinacms/tinacms` @ `main` (`b56dad4`).\n* Deployed artefact validated: `next-tinacms-s3@21.0.3` handler logic, exercised against `@aws-sdk/client-s3@3.665.x` via `aws-sdk-client-mock@4.1.0` (the AWS SDK signs the URL identically whether the bucket is real or mocked).\n* Affected file(s):\n * `packages/next-tinacms-s3/src/handlers.ts:67-90` \u2014 `GET ?key=` returns presigned `PutObjectCommand` URL with attacker-chosen `Key`.\n * `packages/next-tinacms-s3/src/handlers.ts:199-223` \u2014 `DELETE` reads `[, objectKey] = media` and issues `DeleteObjectCommand` against attacker-chosen `Key`.\n * `packages/next-tinacms-dos/src/handlers.ts:79-152` and `:249-278` \u2014 same write/delete pattern, plus a server-side upload that builds the key with `path.join(mediaRoot, prefix + filename)` over attacker-controlled `directory` and `filename`.\n * `packages/next-tinacms-azure/src/handlers.ts:44-95` \u2014 `uploadMedia` writes `path.join(directory, filename)` with both fields attacker-controlled (no `mediaRoot` configured at all); `deleteAsset` deletes any blob in the container.\n * `packages/next-tinacms-cloudinary/src/handlers.ts:193-204` \u2014 `cloudinary.uploader.destroy(public_id)` over attacker-chosen `public_id`.\n* CWE: CWE-639 \u2014 Authorization Bypass Through User-Controlled Key. Adjacent: CWE-284 (Improper Access Control), CWE-862 (Missing Authorization on the per-key authority check).\n* OWASP 2021: **A01:2021 \u2014 Broken Access Control** (the operator\u0027s intended `mediaRoot` boundary is enforced only on listing, not on writes or deletes). Secondary: A04:2021 \u2014 Insecure Design (every adapter independently re-implements the same broken pattern).\n\n## Vulnerable code\n\n`packages/next-tinacms-s3/src/handlers.ts:39-98`:\n\n```ts\nexport const createMediaHandler = (config: S3Config, options?: S3Options) =\u003e {\n const client = new S3Client(config.config);\n const bucket = config.bucket;\n let mediaRoot = config.mediaRoot || \u0027\u0027; // (1)\n if (mediaRoot) { /* normalise to \"media/\" form */ }\n\n return async (req: NextApiRequest, res: NextApiResponse) =\u003e {\n const isAuthorized = await config.authorized(req, res);\n if (!isAuthorized) {\n res.status(401).json({ message: \u0027sorry this user is unauthorized\u0027 });\n return;\n }\n switch (req.method) {\n case \u0027GET\u0027:\n if (req.query.key) {\n const expiresIn: number =\n (req.query.expiresIn \u0026\u0026 Number(req.query.expiresIn)) || 3600; // (2)\n const s3_key = req.query.key\n ? Array.isArray(req.query.key) ? req.query.key[0] : req.query.key\n : null;\n if (!s3_key) return res.status(400).json({ message: \u0027key is required\u0027 });\n if (await keyExists(client, bucket, s3_key)) {\n return res.status(400).json({ message: \u0027key already exists\u0027 }); // (3)\n }\n const signedUrl = await getUploadUrl(bucket, s3_key, expiresIn, client); // (4)\n return res.json({ signedUrl, src: cdnUrl + s3_key });\n }\n return listMedia(req, res, client, bucket, mediaRoot, cdnUrl); // (5)\n case \u0027DELETE\u0027:\n return deleteAsset(req, res, client, bucket); // (6)\n```\n\n`packages/next-tinacms-s3/src/handlers.ts:199-223`:\n\n```ts\nasync function deleteAsset(req, res, client, bucket) {\n const { media } = req.query;\n const [, objectKey] = media as string[]; // (7)\n const params: DeleteObjectCommandInput = { Bucket: bucket, Key: objectKey };\n const command = new DeleteObjectCommand(params);\n ...\n}\n```\n\nAt **(1)** the operator configures `mediaRoot` (e.g. `\"media/\"`), and the package\u0027s `README` documents this as the directory the IAM key is scoped to. At **(4)** the handler signs a `PutObjectCommand` with `Key: s3_key` taken verbatim from `req.query.key`. Nothing between (1) and (4) verifies that `s3_key` starts with `mediaRoot`, so any path the IAM key can reach is fair game. The only filter is the `keyExists` check at **(3)**, which prevents *overwrite* of an existing object but not creation of arbitrary new ones (and not overwrite of objects the IAM key cannot `HeadObject`). At **(2)** the validity window of the produced URL is also attacker-controlled, capped only by AWS SigV4\u0027s 7-day hard limit. At **(5)** the *list* path **does** prefix-join `mediaRoot` (`Prefix: mediaRoot ? path.join(mediaRoot, prefix) : prefix`), demonstrating that the boundary was understood to exist \u2014 it just isn\u0027t enforced on writes. At **(6)** + **(7)** delete extracts the second URL segment into `objectKey` with no prefix check, so `DELETE /api/s3/media/x/anything-in-the-bucket` is a valid arbitrary-key delete primitive.\n\nFor contrast, the same package\u0027s `listMedia` (line 139) does write `Prefix: mediaRoot ? path.join(mediaRoot, prefix) : prefix`, and `stripMediaRoot` (line 100) exists explicitly to peel `mediaRoot` off keys returned to the client \u2014 so the codebase models `mediaRoot` as a security boundary on the read side. The write and delete sides simply forgot to apply it.\n\nThe same misalignment is duplicated in three sibling packages:\n\n* `packages/next-tinacms-dos/src/handlers.ts:115-125` \u2014 upload builds `Key: mediaRoot ? path.join(mediaRoot, prefix + filename) : prefix + filename` over attacker-controlled `prefix` (from `req.body.directory`) and `filename` (from `multer`\u0027s `file.originalname`); `path.join` collapses `..` segments, so a `directory` of `../..` plus a chosen `filename` lands at any key in the bucket. Lines 249-278 reproduce the S3 delete-by-second-segment pattern.\n* `packages/next-tinacms-azure/src/handlers.ts:44-95` \u2014 `uploadMedia` writes a blob at `path.join(directory, filename)` with both values straight out of `formData`. `next-tinacms-azure` has no `mediaRoot` config at all (`AzureBlobStorageConfig` in `src/types.ts`), so the entire container is writable / deletable by any authorized user.\n* `packages/next-tinacms-cloudinary/src/handlers.ts:193-204` \u2014 `deleteAsset` calls `cloudinary.uploader.destroy(public_id)` over the attacker-chosen second segment, deleting any asset in the cloud. The same handler\u0027s `listMedia` (line 110) interpolates `mediaListOptions.directory` directly into a Cloudinary search-expression DSL string (`folder=\"${directory}\"`), giving an authorized user full search-expression injection \u2014 out of scope for this finding but worth a separate report.\n\n## Reproduction (validated locally)\n\nEnvironment: Node 22, `@aws-sdk/client-s3@3.665.0`, `@aws-sdk/s3-request-presigner@3.665.0`, `aws-sdk-client-mock@4.1.0`. The harness vendors `createMediaHandler` byte-for-byte from `packages/next-tinacms-s3/src/handlers.ts` and runs it against a mocked `S3Client`. The AWS SDK signs the URL identically whether the bucket exists \u2014 the resulting URL is the same one a real S3 deployment would hand back to the editor\u0027s browser, so it would PUT against a real bucket without further help.\n\nPoC layout under `/Users/admin/joplin_research/tinacms-s3-poc/`:\n\n```\npackage.json (deps only)\nhandler-vendored.mjs (verbatim copy of createMediaHandler, types stripped)\npoc.mjs (four exhibits exercising the handler)\n```\n\nHandler is configured the way the package\u0027s `README` documents:\n\n```js\nconst handler = createMediaHandler({\n config: { region: \u0027us-east-1\u0027, credentials: { accessKeyId: \u0027\u2026\u0027, secretAccessKey: \u0027\u2026\u0027 } },\n bucket: \u0027editor-media-bucket\u0027,\n mediaRoot: \u0027media\u0027, // editors are \"scoped to media/\"\n authorized: async () =\u003e true, // typical wiring: TinaCloud verified user\n});\n```\n\nRun:\n\n```bash\n$ cd /Users/admin/tinacms-s3-poc \u0026\u0026 node poc.mjs\n--- Exhibit A: presigned PUT URL for arbitrary bucket key ---\n HTTP status : 200\n signedUrl : https://editor-media-bucket.s3.us-east-1.amazonaws.com/index.html?X-Amz-Algorithm=AWS4-HMAC-SHA256\u0026X-Amz-Content-Sha256=UNSIGNED-PAYLOAD\u0026X-Amz-Credential=AKIAFA...\n src : https://editor-media-bucket.s3.us-east-1.amazonaws.com/index.html\n signed Key : /index.html\n RESULT : BYPASS (signed URL writes outside media/)\n\n--- Exhibit B: cross-tenant overwrite via attacker-chosen key ---\n signed Key : /tenant-victim/posts/announcement.mdx\n RESULT : BYPASS (cross-tenant write primitive granted)\n\n--- Exhibit C: arbitrary-key DELETE via [...media] route ---\n HTTP status : 200\n S3 Bucket : editor-media-bucket\n S3 Key : tenant-victim/posts/announcement.mdx\n RESULT : BYPASS (arbitrary-key DELETE granted)\n\n--- Exhibit D: attacker-controlled ?expiresIn ---\n X-Amz-Expires: 604800 sec\n RESULT : BYPASS (URL valid far longer than the 1h default)\n```\n\nVerification, in detail:\n\n1. **Exhibit A** \u2014 `GET /api/s3/media?key=index.html`. `mediaRoot=media/` is configured but never consulted on the write path. The handler hands back a SigV4 URL whose path is `/index.html`. PUT\u0027ing any body to that URL would create the bucket-root object `index.html` against the operator\u0027s IAM credentials. For a deployment that fronts the bucket with CloudFront / S3-website hosting, this is a one-shot site-defacement primitive (and, for any CSP that trusts the bucket, a one-shot stored-XSS primitive against the published site).\n\n2. **Exhibit B** \u2014 same primitive, attacker-chosen key `tenant-victim/posts/announcement.mdx`. In the multi-tenant TinaCloud / TinaCMS Cloud deployment shape (one bucket shared across tenants, each tenant assigned a `mediaRoot/\u003ctenant\u003e/` prefix), a Tenant A editor receives a presigned PUT URL for any Tenant B key. Cross-tenant content tampering with no further bug needed.\n\n3. **Exhibit C** \u2014 `DELETE /api/s3/media/anything-here-is-ignored/tenant-victim%2Fposts%2Fannouncement.mdx`. The handler reads the catch-all as `req.query.media = [\u0027anything-here-is-ignored\u0027, \u0027tenant-victim/posts/announcement.mdx\u0027]`, destructures to `objectKey = media[1]`, dispatches `DeleteObjectCommand({ Bucket: \u0027editor-media-bucket\u0027, Key: \u0027tenant-victim/posts/announcement.mdx\u0027 })`. The mock confirms the captured command\u0027s `Key` is the attacker-supplied string. Real S3 will honour the same call. (The mock-captured call confirms the *handler\u0027s* behaviour; the real S3 call requires only `s3:DeleteObject` on the bucket, which the package\u0027s `README` instructs operators to grant.)\n\n4. **Exhibit D** \u2014 `?expiresIn=604800` (7 days, the SigV4 ceiling). The handler accepts it, the resulting `X-Amz-Expires=604800`. Combined with Exhibit A, an attacker who briefly compromises a CMS session (e.g. via a stolen idle browser session or the dev-server CSRF write described in finding 06) can mint a long-lived offline write primitive \u2014 usable for a week with no further interaction with the CMS.\n\nThe four exhibits together: cross-mediaRoot write, cross-tenant write, arbitrary-key delete, and long-lived signed-URL minting.\n\n## Impact\n\n* **Cross-tenant / cross-mediaRoot write.** In any deployment where the bucket holds anything other than this one editor\u0027s `mediaRoot` (multi-tenant TinaCloud, shared corporate bucket, bucket-backed static site), an authorized editor obtains write authority over every key the IAM credential can reach. Concretely: defacement of a static site fronted by the bucket; cross-tenant content tampering; replacement of `*.html`, `*.js`, `*.json` assets that downstream consumers trust. (Exhibits A, B; `handlers.ts:67-90`.)\n* **Stored XSS via uploaded HTML.** S3 returns objects with the `Content-Type` the upload supplies. The presigned `PutObjectCommand` URL carries no `Content-Type` constraint \u2014 the attacker\u0027s `PUT` chooses it. An editor can therefore write an HTML / SVG / JS payload to the bucket-root, and any CDN or origin that serves bucket objects directly to an authenticated SaaS surface inherits stored XSS in that origin.\n* **Arbitrary-key delete (data destruction).** Through `[...media]` the handler treats the second URL segment as a free-form object key. An editor can wipe any object the IAM key can `s3:DeleteObject`, including non-media artefacts like deployment manifests, backups, or other tenants\u0027 files. (Exhibit C; `handlers.ts:199-223`.)\n* **Bucket-policy implications.** The `README` (lines 38-90) tells operators to grant the IAM key `s3:PutObject`, `s3:PutObjectAcl`, `s3:DeleteObject`, and `s3:ListBucket` on the *whole* bucket. The README implies the application code constrains the editor\u0027s actions to `mediaRoot`. Because the application code does not, every operator who follows the README has \u2014 without realising \u2014 granted every CMS editor full write/delete on the whole bucket.\n* **Long-lived offline write primitive.** `expiresIn` is attacker-controlled and not capped by the handler. A single GET request mints a URL valid for up to 7 days (AWS SigV4 ceiling). An attacker who briefly compromises a CMS session can stash one such URL and continue writing arbitrary objects long after the session is revoked. (Exhibit D.)\n* **Same-shape exposure on every other first-party media adapter.** `next-tinacms-dos` (DigitalOcean Spaces, S3-compatible), `next-tinacms-azure` (Blob Storage), and `next-tinacms-cloudinary` (Cloudinary) all duplicate the broken pattern. Azure has *no* mediaRoot config at all, so the boundary that `next-tinacms-s3` advertises but doesn\u0027t enforce isn\u0027t even nominally present in `next-tinacms-azure`.",
"id": "GHSA-8mq9-5fw2-5rm4",
"modified": "2026-08-21T18:31:05Z",
"published": "2026-08-19T21:56:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tinacms/tinacms/security/advisories/GHSA-8mq9-5fw2-5rm4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59992"
},
{
"type": "WEB",
"url": "https://github.com/tinacms/tinacms/pull/7088"
},
{
"type": "WEB",
"url": "https://github.com/tinacms/tinacms/commit/d44558e9b4502d4f4fc2c970d22985339fe2b6ce"
},
{
"type": "PACKAGE",
"url": "https://github.com/tinacms/tinacms"
},
{
"type": "WEB",
"url": "https://github.com/tinacms/tinacms/releases/tag/next-tinacms-s3@23.0.4"
}
],
"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"
}
],
"summary": "Tina: Broken Access Control: arbitrary bucket-key write/delete in `next-tinacms-s3` (and sibling production media adapters)"
}
GHSA-8MXC-2QJP-X88P
Vulnerability from github – Published: 2023-06-07 03:30 – Updated: 2024-04-04 04:38The Frontend File Manager plugin for WordPress is vulnerable to Unauthenticated Arbitrary Post Deletion in versions up to, and including, 18.2. This is due to lacking authentication protections and lacking a security nonce on the wpfm_delete_file AJAX action. This makes it possible for unauthenticated attackers to delete any posts and pages on the site.
{
"affected": [],
"aliases": [
"CVE-2021-4359"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-07T02:15:14Z",
"severity": "MODERATE"
},
"details": "The Frontend File Manager plugin for WordPress is vulnerable to Unauthenticated Arbitrary Post Deletion in versions up to, and including, 18.2. This is due to lacking authentication protections and lacking a security nonce on the wpfm_delete_file AJAX action. This makes it possible for unauthenticated attackers to delete any posts and pages on the site.",
"id": "GHSA-8mxc-2qjp-x88p",
"modified": "2024-04-04T04:38:28Z",
"published": "2023-06-07T03:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4359"
},
{
"type": "WEB",
"url": "https://blog.nintechnet.com/wordpress-frontend-file-manager-plugin-fixed-multiple-critical-vulnerabilities"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=2554359%40nmedia-user-file-uploader\u0026new=2554359%40nmedia-user-file-uploader\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/84c61d00-20c1-4176-a74d-ea6ff6220f26?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-8MXF-4389-Q8J9
Vulnerability from github – Published: 2025-05-14 12:31 – Updated: 2025-05-14 12:31Unauthorized access to "/api/Token/gettoken" endpoint in EZD RP allows file manipulation.This issue affects EZD RP in versions before 20.19 (published on 22nd August 2024).
{
"affected": [],
"aliases": [
"CVE-2025-4430"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-14T11:16:36Z",
"severity": "HIGH"
},
"details": "Unauthorized access to \"/api/Token/gettoken\" endpoint in EZD RP allows file manipulation.This issue affects EZD RP in versions before 20.19 (published on 22nd August 2024).",
"id": "GHSA-8mxf-4389-q8j9",
"modified": "2025-05-14T12:31:12Z",
"published": "2025-05-14T12:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4430"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2025/05/CVE-2025-4430"
},
{
"type": "WEB",
"url": "https://www.gov.pl/web/ezd-rp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-8MXH-W9W9-HRMG
Vulnerability from github – Published: 2025-01-07 06:32 – Updated: 2026-04-08 21:32The FancyPost – Best Ultimate Post Block, Post Grid, Layouts, Carousel, Slider For Gutenberg & Elementor plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the handle_block_shortcode_export() function in all versions up to, and including, 6.0.0. This makes it possible for authenticated attackers, with Subscriber-level access and above, to export shortcodes.
{
"affected": [],
"aliases": [
"CVE-2024-10536"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-07T06:15:13Z",
"severity": "MODERATE"
},
"details": "The FancyPost \u2013 Best Ultimate Post Block, Post Grid, Layouts, Carousel, Slider For Gutenberg \u0026 Elementor plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the handle_block_shortcode_export() function in all versions up to, and including, 6.0.0. This makes it possible for authenticated attackers, with Subscriber-level access and above, to export shortcodes.",
"id": "GHSA-8mxh-w9w9-hrmg",
"modified": "2026-04-08T21:32:58Z",
"published": "2025-01-07T06:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10536"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/post-block/trunk/custom-fields/options/admin-backup.php#L171"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3215521/post-block/trunk/custom-fields/options/admin-backup.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/e573648e-215f-4858-a4d3-a3e85119dbcf?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"
}
]
}
GHSA-8MXJ-8QFG-PG7X
Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53SecurEnvoy SecurMail before 9.2.501 allows remote attackers to spoof transmission of arbitrary e-mail messages, resend e-mail messages to arbitrary recipients, or modify arbitrary message bodies and attachments by leveraging missing authentication and authorization.
{
"affected": [],
"aliases": [
"CVE-2018-7702"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-15T01:29:00Z",
"severity": "CRITICAL"
},
"details": "SecurEnvoy SecurMail before 9.2.501 allows remote attackers to spoof transmission of arbitrary e-mail messages, resend e-mail messages to arbitrary recipients, or modify arbitrary message bodies and attachments by leveraging missing authentication and authorization.",
"id": "GHSA-8mxj-8qfg-pg7x",
"modified": "2022-05-13T01:53:24Z",
"published": "2022-05-13T01:53:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7702"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/44285"
},
{
"type": "WEB",
"url": "https://www.sec-consult.com/en/blog/advisories/multiple-critical-vulnerabilities-in-securenvoy-securmail/index.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2018/Mar/29"
}
],
"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-8P26-V8P8-WHM6
Vulnerability from github – Published: 2022-12-20 18:30 – Updated: 2022-12-20 18:30In getNearbyAppStreamingPolicy of DevicePolicyManagerService.java, there is a missing permission check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-235821829
{
"affected": [],
"aliases": [
"CVE-2022-20511"
],
"database_specific": {
"cwe_ids": [
"CWE-276",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-16T16:15:00Z",
"severity": "MODERATE"
},
"details": "In getNearbyAppStreamingPolicy of DevicePolicyManagerService.java, there is a missing permission check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-235821829",
"id": "GHSA-8p26-v8p8-whm6",
"modified": "2022-12-20T18:30:19Z",
"published": "2022-12-20T18:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20511"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2022-12-01"
}
],
"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"
}
]
}
Mitigation
- 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
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
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
- 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
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.