critical

CVE-2023-35169

php-imap vulnerable to RCE through a directory traversal vulnerability

Published 23 Jun 2023Modified 17 Jun 2026CWE 22

In the Trivy database since at least 24 Oct 2026, 07:11 UTCWhen it arrived before that build is not recorded.

Severity by source

NVD9.8CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

GHSA9.1CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

Trivy's own label is CRITICAL. Rated critical by NVD, GHSA.

Description

PHP-IMAP is a wrapper for common IMAP communication without the need to have the php-imap module installed / enabled. Prior to version 5.3.0, an unsanitized attachment filename allows any unauthenticated user to leverage a directory traversal vulnerability, which results in a remote code execution vulnerability. Every application that stores attachments with `Attachment::save()` without providing a `$filename` or passing unsanitized user input is affected by this attack. An attacker can send an email with a malicious attachment to the inbox, which gets crawled with `webklex/php-imap` or `webklex/laravel-imap`. Prerequisite for the vulnerability is that the script stores the attachments without providing a `$filename`, or providing an unsanitized `$filename`, in `src/Attachment::save(string $path, string $filename = null)`. In this case, where no `$filename` gets passed into the `Attachment::save()` method, the package would use a series of unsanitized and insecure input values from the mail as fallback. Even if a developer passes a `$filename` into the `Attachment::save()` method, e.g. by passing the name or filename of the mail attachment itself (from email headers), the input values never get sanitized by the package. There is also no restriction about the file extension (e.g. ".php") or the contents of a file. This allows an attacker to upload malicious code of any type and content at any location where the underlying user has write permissions. The attacker can also overwrite existing files and inject malicious code into files that, e.g. get executed by the system via cron or requests. Version 5.3.0 contains a patch for this issue.

Affected packages and fixed versions

Source	Package	Fixed in
composer::GitHub Security Advisory Composer	webklex/laravel-imap, webklex/php-imap	5.3.0

Show all 2 entries from 1 source

Source	Package	Fixed in
composer::GitHub Security Advisory Composer	webklex/laravel-imap	5.3.0
composer::GitHub Security Advisory Composer	webklex/php-imap	5.3.0

References

What Attestkeep does with this

Inside your cluster, without you opening a spreadsheet.

KnowsThe scanner refreshes its vulnerability database every six hours.

FindsEvery admitted image is rescanned every 24 hours by default (scan.rescanInterval). When Trivy rates this vulnerability critical for the image's package source, it appears in the image's findings by name. Findings without a fix are left out unless includeUnfixed is on.

Tells youA critical_finding event goes to the channels subscribed to it: e-mail, Slack, Teams, a webhook, Jira, GitLab or GitHub.

RefusesWith a policy that blocks critical findings, a pod with this image is refused at admission, a rollback to it included. Pods already running are not evicted.

RecordsEach decision is recorded with the policy that ran and its hash, then sealed under a signed checkpoint.

Try Attestkeep

Read the docs