Security readout for executives and security teams
Plain-English summary
Applications using plank/laravel-mediable through 6.4.0 may accept a dangerous upload disguised as an image when they trust a user-provided MIME type. This can place executable PHP code on the server. Risk is critical for exposed upload features using the vulnerable configuration, but the supplied sources do not establish that every installation is exploitable.
Executive priority
Treat as an immediate investigation for internet-facing upload services. Confirm version and MIME-handling configuration first, then contain vulnerable paths. The maximum severity reflects potential complete confidentiality, integrity, and availability impact, although the supplied evidence does not prove universal exposure or active exploitation.
Technical view
The issue is CWE-434 arbitrary file upload. A remote, unauthenticated attacker can label PHP content with a benign image MIME type when the application accepts or prefers client-supplied MIME information. The supplied CVSS v2 score is 10.0. Exploitability depends on package version and application upload configuration.
Likely exposure
Prioritize internet-facing Laravel applications using laravel-mediable 6.4.0 or earlier that accept uploads and trust client-supplied MIME types. Installations without that configuration are not shown as affected by the supplied evidence. Actual impact also depends on how uploaded files are stored and served.
Exploitation context
The source bundle marks this CVE as absent from KEV and provides no evidence of active exploitation or a public exploit. The attack is described as remote, low-complexity, and unauthenticated under the vulnerable configuration. Treat exposed upload endpoints as urgent despite the incomplete exploitation evidence.
Researcher notes
The vulnerable condition is configuration-dependent: affected package versions alone do not prove exploitability. The supplied bundle identifies versions through 6.4.0 but does not name a fixed release, patch, or vendor-endorsed mitigation. Testing should remain controlled and non-destructive, focusing on MIME provenance, validation decisions, storage behavior, and executable-file isolation.
Mitigation direction
- Inventory applications using laravel-mediable 6.4.0 or earlier.
- Identify upload paths that accept or prefer client-supplied MIME types.
- Stop trusting client MIME declarations; validate file content using server-derived information.
- Restrict uploaded files from executable locations while remediation is assessed.
- Check current project or vendor guidance for a supported fixed version or configuration.
Validation and detection
- Confirm the installed version from dependency records and deployment artifacts.
- Review upload configuration and code for reliance on client-supplied MIME types.
- Map public and authenticated endpoints that pass files into laravel-mediable.
- Verify uploaded content cannot execute as PHP from its storage location.
- Review historical uploads for PHP content, misleading extensions, or image MIME mismatches.
Public sources used
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
CWE-434: File access and web shell behavior lookup
File traversal and upload weaknesses can lead teams to review file, web shell, execution, and collection telemetry. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Open ATT&CK lookupFile access behavior lookup
The CVE wording references file access or upload behavior, so file telemetry and web shell review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
Open ATT&CK lookupCVE-2026-4809 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
Open ATT&CK lookup- Severity
- Critical
- CVSS
- 10 (2.0)
- Known Exploited
- No
- Published
Vector: AV:N/AC:L/Au:N/C:C/I:C/A:C
CNA and ADP enrichment extracted from CVE v5
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
SSVC decision data
CVSS vector scores
3 official scoresWe collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
AV:N/AC:L/Au:N/C:C/I:C/A:C1010TuranSecCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H3.95.9TuranSecCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N——TuranSecVulnerability scoring details
Base CVSS 4.0 score
9.3CriticalVector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Base CVSS 3.1 score
9.8CriticalVector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Base CVSS 2.0 score
10CriticalVector: AV:N/AC:L/Au:N/C:C/I:C/A:C
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
- CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
- CVE publishedCVE Program
The CVE record was published.
- CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.
ADP provider summaries
Source materials
- CVE List V5 sourceCVE List V5
- Project repositoryCVE reference, TuranSec · third-party-advisory
- Release 6.4.0CVE reference, TuranSec · third-party-advisory
Products and packages named in the record
CWE details
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
Unrestricted Upload of File with Dangerous Type
Unrestricted Upload of File with Dangerous Type represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.