GHSA-FR76-5637-W3G9

Vulnerability from github – Published: 2026-03-25 20:00 – Updated: 2026-03-27 21:35
VLAI
Summary
Sharp has Unrestricted File Upload via Client-Controlled Validation Rules
Details

Summary

The code16/sharp Laravel admin panel package contains a vulnerability in its file upload endpoint that allows authenticated users to bypass all file type restrictions.

Details

The upload endpoint within the ApiFormUploadController accepts a client-controlled validation_rule parameter. This parameter is directly passed into the Laravel validator without sufficient server-side enforcement. By intercepting the request and sending validation_rule[]=file, an attacker can completely bypass all MIME type and file extension restrictions. The vulnerable code is located in src/Http/Controllers/Api/ApiFormUploadController.php at line 24.

Impact

This vulnerability leads to several critical security risks:

Attackers can upload arbitrary files, including PHP webshells, to the server. For more details on the package, visit: https://github.com/code16/sharp

MIME type and extension validation can be bypassed entirely via client-controlled rules. Review the CWE definition here: https://cwe.mitre.org/data/definitions/434.html

If the storage disk is configured to be publicly accessible, this can lead to Remote Code Execution (RCE). See the vendor repository: https://github.com/code16/sharp

(Note: Under default configurations, executing uploaded PHP files directly is not possible unless a public disk configuration is in place.)

Patches

This issue has been addressed by removing the client-controlled validation rules and strictly defining upload rules server-side. The fix is available in pull request https://github.com/code16/sharp/pull/714.

Workarounds

  • Restrict Disk Access: Ensure that the storage disk used for Sharp uploads is strictly private. Under default configurations, an attacker cannot directly execute uploaded PHP files unless a public disk configuration is explicitly used. For more details on Laravel disk configurations, visit: https://laravel.com/docs/13.x/filesystem

Credits

Reported by zaurgsynv.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "code16/sharp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.20.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33687"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T20:00:24Z",
    "nvd_published_at": "2026-03-26T22:16:31Z",
    "severity": "HIGH"
  },
  "details": "### Summary \nThe `code16/sharp` Laravel admin panel package contains a vulnerability in its file upload endpoint that allows authenticated users to bypass all file type restrictions.\n\n### Details\nThe upload endpoint within the `ApiFormUploadController` accepts a client-controlled `validation_rule` parameter. This parameter is directly passed into the Laravel validator without sufficient server-side enforcement. By intercepting the request and sending `validation_rule[]=file`, an attacker can completely bypass all MIME type and file extension restrictions. The vulnerable code is located in `src/Http/Controllers/Api/ApiFormUploadController.php` at line 24.\n\n### Impact\nThis vulnerability leads to several critical security risks:\n\nAttackers can upload arbitrary files, including PHP webshells, to the server. For more details on the package, visit: https://github.com/code16/sharp\n\nMIME type and extension validation can be bypassed entirely via client-controlled rules. Review the CWE definition here: https://cwe.mitre.org/data/definitions/434.html\n\nIf the storage disk is configured to be publicly accessible, this can lead to Remote Code Execution (RCE). See the vendor repository: https://github.com/code16/sharp\n\n(Note: Under default configurations, executing uploaded PHP files directly is not possible unless a public disk configuration is in place.)\n\n### Patches\nThis issue has been addressed by removing the client-controlled validation rules and strictly defining upload rules server-side. The fix is available in pull request https://github.com/code16/sharp/pull/714.\n\n### Workarounds\n- Restrict Disk Access: Ensure that the storage disk used for Sharp uploads is strictly private. Under default configurations, an attacker cannot directly execute uploaded PHP files unless a public disk configuration is explicitly used. For more details on Laravel disk configurations, visit: https://laravel.com/docs/13.x/filesystem\n\n### Credits\nReported by [zaurgsynv](https://github.com/zaurgsynv).",
  "id": "GHSA-fr76-5637-w3g9",
  "modified": "2026-03-27T21:35:55Z",
  "published": "2026-03-25T20:00:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/code16/sharp/security/advisories/GHSA-fr76-5637-w3g9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33687"
    },
    {
      "type": "WEB",
      "url": "https://github.com/code16/sharp/pull/714"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/code16/sharp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/code16/sharp/releases/tag/v9.20.0"
    },
    {
      "type": "WEB",
      "url": "https://laravel.com/docs/13.x/filesystem"
    }
  ],
  "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": "Sharp has Unrestricted File Upload via Client-Controlled Validation Rules"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…