gwillcox-r7 (536)

Last Login: January 10, 2022
1st Place

gwillcox-r7's Latest (20) Contributions

Sort by:
Filter by:

Sorry don’t mean to offend but the version you posted as exploiting is Windows 10,0.19041.264, which as noted at is an Insider Preview version of Windows 10 v2004 from October 2020. I’d find this more believable if you ran the tests on a December 2021 build of Windows 10 which would have patched CVE-2021-31166 but not CVE-2022-21907.

Additionally Windows 10 v2004 stopped being support after 2021 which is why if you look at you will see no mention of a patch for Windows 10 v2004 for CVE-2022-21907.

Understand that given the stack trace is pretty much exactly the same as the blog post I mentioned combined with the fact that your demo is running against a very outdated version of Windows that is no longer supported, it looks like you were exploiting CVE-2021-31166. If you can demo the bug against something like 10.0.19044.1415, or even something like 10.0.19043.1415, I’d find that to be a lot more of an accurate test as you are testing it against the December 2021 patches vs October 2020 patches.


Your assessment is correct however the bug you are describing is for CVE-2021-31166 as mentioned at This was an earlier bug in http.sys that was patched in March 2021 which had a PoC published at

This is not CVE-2022-21907, which is a bug in the HTTP Trailer Support feature, not the Accept-Encoding feature as you have shown above.

Feel free to move your assessment to CVE-2021-31166 if you want though, but I don’t think this assessment is for CVE-2022-21907.

Technical Analysis

Looks like this is your fairly typical maliciously crafted document exploit for Microsoft Office. These bugs are used all the time by APTs and other groups simply cause its relatively easy to convince people to open documents given the right context, and even though some people will be fairly vigilant, all it takes is compromising one user to get an initial foothold into a target network.

This bug appears to affect all Microsoft Office versions since 2013 up to and including the latest Microsoft Office online solutions and also including Microsoft Sharepoint Servers from 2013 onwards, meaning that it has quite a wide range of potential targets. User interaction is required though in the form of opening a malicious document,

Given the supposedly low complexity of exploiting this vulnerability combined with the wide range of target that it can exploit, I’d expect to see exploits for this vulnerability in the wild over the coming few months.

Technical Analysis

Update: There appears to be some initial patch analysis on this vulnerability at which seems to suggest the patched functions are UlFastSendHttpResponse, UlpAllocateFastTracker UlpFastSendCompleteWorker, UlpFreeFastTracker, and UlAllocateFastTrackerToLookaside. They also note that based on their analysis a safe assumption may be that the vulnerable code path is hit first in UlFastSendHttpResponse and some of the fixup / mitigations were applied to memory chunks in the other functions. Analysis is still ongoing though.

There has been a lot of confusion r.e this vulnerability, which is a RCE in the HTTP Trailer Support feature of the http.sys component which is responsible for the HTTP Protocol stack used by several high privileged Windows components. The best writeup I was able to find was at however note that investigation is still ongoing and its likely that things will change over time.

First off, to be clear, despite http.sys appearing to be associated with IIS, this is not in itself an IIS vulnerability. As noted at, you can find which components are using http.sys by running the command netsh http show servicestate. You’ll likely find more components using it then you thought, for example Intel components use this for some odd built in HTTP server (yeah I’m not sure either but there you go).

Secondly, whilst the vulnerability affects Windows 10 1809 and Windows Server 2019 and later, by default, and only on Windows 10 1809 and Windows Serve r 2019, HKLM:\System\CurrentControlSet\Services\HTTP\Parameter\EnableTrailerSupport is set to 0 by default, thus disabling the vulnerable trailers feature. This means these versions are not vulnerable out of the box, however if the HKLM:\System\CurrentControlSet\Services\HTTP\Parameter\EnableTrailerSupport registry key is set to 1 then they are. All other affected versions of Windows are vulnerable using their default settings.

As this is a kernel level vulnerability and it being exploited remotely I imagine now would be a good time to remind people that RCE bugs in the Windows kernel have become increasingly hard to exploit. Whilst Windows 7 was easier to exploit due to lack of a number of mitigations, with Windows 10 and Windows 11, several mitigations have been implemented into the Windows kernel specifically to prevent RCE kernel exploits and from my experience they work very well to this effect (local privilege escalation attacks are another story which still needs improvement though).

Finally as for those wondering what Trailer support is anyway (like myself), notes that RFC7230 specifies the protocol for trailer support, noting that it only makes sense if Transfer-Encoding: chunked is used in a request to a server. This allows a requestor to essentially chunk the request up into several smaller packets and then only send the headers for the request after the request body has been sent. The original idea behind this was that the request body may be generated over time and we want to start sending data as it becomes available to speed things up and ensure quicker operations.

Hopefully that helps, still not a lot of detail on this right now and there will likely need to be some patch diffing going on before people are able to better determine the root cause of this issue, but for now I’d say patch if you can whilst also keeping in mind a working exploit will likely take time to develop if its possible given Microsoft’s kernel level mitigations for Windows 10.

Technical Analysis

Of all the bugs in January 2022’s Patch Tuesday analysis, I think this one has to be hands down the most complex one to exploit. There is very little information from the advisory on what this bug is however here is what I can piece together from the limited bits of information that are available.

Supposively this affects virtual machines, although its a little confusing cause if we look at the list of affected products we can see this goes all the way back to Windows 7, Hyper-V was released in 2008 with Windows Server 2008, which means that Windows 7 SP1 would also make sense since Windows 7 was released on October 22, 2019. This makes me believe that this is likely related to HyperV, but I cannot confirm this 100% at this time.

The second interesting thing is that the vulnerability is in IDE. Looking this up we can find where its noted that IDE stands for Integrated Drive Electronics and is a standard that defines the connection between a bus line on a motherboard and the computer’s disk storage devices.

Therefore if I had to take a stab at this I’d say this is some sort of vulnerability in HyperV that is related to how disk drives interface with the Virtual Machine, specifically in how HyperV virtualizes the IDE protocol when interacting with virtual disks.

Overall as this was found by Microsoft Research and Engineering and the attack complexity is listed as High, I doubt any public details will be coming out on this anytime soon, however if your organization uses Hyper-V and advanced technical attackers are within your risk profile, then I’d recommend patching this vulnerability ASAP. Otherwise, do try to patch this vulnerability when you can, but note that there are plenty of other vulns that are likely higher risk than this one in this months advisory.

Technical Analysis

Huh so this one is a bit of a doozy. On the one hand we have Microsoft Exchange Server, which, unless you have been living under a rock, has been exploited many times in the past, as evidenced here, here, and here. Basically Microsoft Exchange Server has a giant target on its back and attackers are all too happy to exploit it given any opportunity to do so.

What makes this bug interesting though is that unlike most of the other vulnerabilities which were exploitable remotely, this one not only requires authentication, but also requires local network access of some type. Its also interesting to note that the Scope section of Microsoft’s advisory is marked as Changed, which they take as meaning An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities..

This raises a few questions as it seems to suggest that the initial component used to exploit the vulnerability exists in one security context separate from the Exchange Server security context, which when combined with the Adjacent factor, suggests a rather unusual way of exploiting this vulnerability via some local access, presumably though some component with a different security boundary, which then interacts with the Exchange Server.

Exploitation is however listed as easy and the bug does give you high level permissions on the Exchange Server, so I can see this as being useful for internal attacks once an attacker has gotten initial access into a network. As per usual, it is always advisable to assume that your network has been compromised when considering what to patch; I have personally seen that its often the little vulnerabilities that were ignored instead of being patched combined together that can lead to some of the most unexpected and dangerous impacts to companies.

Overall I’d say this is likely lower on your patch list than other RCE bugs, however given the impact and number of previous exploits for this target, I’d still recommend patching this as soon as possible, presumably once all your RCE bugs have been patched.

Technical Analysis

Privilege escalation in Active Directory Domain Services that allows for elevation of privilege across a network.

Given how popular Active Directory is this is pretty serious and I imagine this will likely be a very popular way to escalate privileges in internal engagements should an exploit come out for this.

Bug is noted as being related to Active Directory Domain Service environments that have incoming trusts, and that the bug allows attackers to escalate privileges across the trust boundary under certain conditions.

The fact that this is labeled as “under certain conditions” leads me to believe that this may not be a default configuration which is why I have labeled it as such in my report. However I would also provide a slight counterpoint to this in that AD networks are often sprawling and complex so there is a good likelihood that this may be enabled in some part of the network even if you are not aware of it.

Definitely one to patch if you are running AD networks.

Technical Analysis

Writeup for this vulnerability is rather interesting and I think a few people may have read the Microsoft advisory somewhat incorrectly.

The attack vector for this is listed as local which is odd given this is listed as an RCE vulnerability in the Windows Security Center API.

However looking at Microsoft’s description closer we can see that the Attack Vector value of Local is also applied if the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability.

Looking further down the assessment we can see the complexity is considered Low, no privileges are required, however User Interaction is marked as Required.

This suggests that it is possible to somehow exploit this vulnerability by either sending the target a request which then opens a prompt that they have to interact with, or by sending them some malicious document which then triggers the vulnerability.

Given this has a high impact on both Confidentiality, Integrity, and Availability I would say this likely gives you pretty high level access should you be able to exploit it successfully.

The patch was likely applied to the wscsvc.dll file given the modification dates and info on the web about how the Windows Security Service works, but I’ll have to do a more in depth analysis to determine what exactly was changed. Hopefully this information is useful for now though.

Technical Analysis

This appears to be a bug in Windows Event Tracing which is a kernel level tracing facility in Windows that allows you to log kernel events or application defined events to a log file. The bug occurs due to something related to Discretionary Access Control Lists or DACLS for short. DACLs in Windows are an access control mechanism made up of a bunch of ACE, or Access Control Entries, put together into a list. Note however that if a DACL does not exist on an object, everyone is allowed access to it and if a DACL is set on an object but not ACE entries are added to the DACL, no one is allowed access to it.

My guess is that somehow it is possible to create a DACL on a specific file or object as any authenticated user that does not have any ACE entries associated with it and thereby cause a component to stop working completely due to its need to access that file. Adding to the fact that this only causes a DoS, is the fact that this bug supposedly only works on Windows 10 1809 and Windows Server 2019, which further limits its impact.

Overall a pretty low impact bug in my opinion.

Technical Analysis

This appears to be a vulnerability in the Windows Platform Binary Table verification, also known as WPBT verification for short. It appears this was originally discovered back in September 2021 by Mickey Shkatov and the researchers of Eclypsium, who published a paper on this titled Everyone Gets a Rootkit where they detailed this bug in greater detail.

Simply put, WPBT was introduced in Windows 8 that is an extension to an earlier protocol known as ACPI, or Advanced Configuration and Power Interface, which was originally designed to efficiently manage energy consumption in PCs. A flaw was found in WPBT verification whereby expired or compromised signatures could still be used to sign a WPBT binary, as these drivers were not in the kernel driver block list, which is stored as a file named driver.stl.

By signing a WPBT binary of the attackers creation with one of these expired or compromised certificates, authenticated attackers could get malicious code to load with kernel privileges when the target device boots up.

WPBT binaries are particularly powerful as they allow OEMS to modify the host operating system during boot. This is often needed to supply vendor-specific drivers, applications and content. As a result, compromising the integrity of this stage of the Windows OS loading process means that an attacker can install a rootkit onto the target system to easily maintain stealthy and persistent access to the target machine.

Its also important to note that this attack works even with Secured-core PCs running with the latest boot protections and mitigations. Therefore this vulnerability fundamentally this undercuts a lot of the new mitigations that were introduced with Windows 10 and Windows 11 to try prevent supply chain compromise and rootkit installation, which is a serious compromise of trust..

Overall I have rated this vulnerability as high on attacker value since this is essentially the highest form of privileges you can possibly get on a Windows OS, going beyond even SYSTEM level access to strike at the very heart of the OS itself, however the exploitability is somewhat lower as you would need to craft a valid WPBT binary, something that would take some time to research since I imagine not many people are familiar with how to do that. Signing it with a compromised/expired certificate though shouldn’t be that hard to do though :)

Technical Analysis

According to this appears to be a patch for the code blogged about at The details on this bug can be found at but I’ll summarize them here for brevity.

The original incomplete patch is explained best by Mitja Kolsek at where he notes that bug was originally considered to be an arbitrary directory deletion bug that allowed a logged on user to delete a folder on the computer.

However upon reviewing the fix KLINUX5 found that it was possible to not only bypass the fix, but also make the vulnerability more impactful.

Specifically by abusing the User Profile Service’s code which creates a temporary user profile folder (to protect against the original user profile folder being damaged etc), and then copies folders and files from the original profile folder to the backup, one can instead place a symbolic link. When this symbolic link is followed, it can allow the attacker to create attacker-writeable folders in a protected location and then perform a DLL hijacking attack against high privileged system processes.

Unfortunately when patching this bug, Microsoft correctly assumed that one should check that the temporary user folder (aka C:\Users\TEMP), is not a symbolic link, but didn’t check to see if any of the folders under C:\Users\TEMP contains a symbolic link.

Note that as noted in this bug does require winning a race condition so exploitation is 100% reliable however there are ways to win the race condition as was shown in the code for the patch bypass published at

I’d keep an eye on this one as KLINIX5 has a habit of finding patch bypasses for his bugs and if he says Microsoft has messed things up again, more than likely there will be another patch bypass for this bug. I’m still looking into exactly what was patched here though.

Technical Analysis

This looks to be a Use-After-Free bug in libarchive 3.4.1 through 3.5.1 that was only recently patched by Microsoft in January 2021, though the details on this bug were public as early as June 2021 in It remains unclear if this was fully fixed though as is still open which references as being the fix, yet that PR is on hold as of today (January 11th 2021), and that relies on which is in turn dependent on All of this leads to a bit of a confusing mess as to if this bug has truely been fixed or not.

This bug occurs in copy_string which is in turn called from do_uncompress_block and process_block. These functions exist within the libarchive/libarchive/archive_read_support_format_rar5.c file, as can be seen by looking at, and are related to parsing RAR5 archive files.

So what is RAR5 archive files? Well turns out according to that RAR4 was the default archive compression mechanism for RAR files. RAR5 is the new compression algorithm that is trying to rival 7ZIP and similar compression formats and is an evolution of the RAR4 format. The article also notes that right now WinRAR is the most likely program to open these newer file formats.

From this we can conclude that this bug most likely occurs when sending a user a RAR5 file and a Windows program that uses the system’s version of the libarchive library attempts to extract the RAR5 file, which will cause a UAF condition that, if controlled, could allow the attacker to gain RCE on a users computer.

Technical Analysis

Original report for this vulnerability can be found at

This vulnerability affects curl 7.20.0 to 7.78.0 inclusive, and occurs due to the commit made at

The bug occurs as when curl connects to a IMAP, POP3, SMTP, or FTP server using STARTTLS to upgrade the connection to a TLS connection. In these scenarios the server can send multiple responses prior to the TLS upgrade, which are then cached by curl.

Unfortunately, when upgrading to TLS, curl would not flush this queue of cached responses and instead would treat these responses as part of the TLS handshake themselves as if they were authenticated.

Attackers could use this to inject fake response data via a man in the middle (MITM) attack when the connection uses POP3 or IMAP as noted by the curl developers.

It is interesting to note that this bug was disclosed via HackerOne in September 2021 but was only fixed by Microsoft in January 2021 as noted at, meaning there was at least a 3 month gap between the bug being public knowledge and it being fixed.

As for the exploitability of this bug, it is fairly low due to the need to be able to conduct a MITM attack against a target user. Additionally using implicit TLS instead of using STARTTLS negates this issue so attackers would have to find a connection specifically using STARTTLS.

It should be noted though that may applications use libcurl, the affected library, even if they don’t explicitly advertise it, so there is a good possibility that a fair number of apps on Windows would use this in some manner.

As a final note, its not directly clear to me why Microsoft rates this as a RCE bug but I imagine they likely found a connection between an attacker MITM’ing a specific connection for one of their apps and forging a fake response that can then be used to trigger some form of RCE. No details are provided on which app this might be though, so the specifics of this remain to be seen.

Technical Analysis

A great overview of this bug is available at which leads on from a description at showing how this bug was exploited in the wild. Essentially, by abusing the ms-appinstaller:// URI handler in Microsoft Windows, one can trick users into thinking that the website is trying to ask them to install software to do something; in the case of the campaign it was to install a PDF viewer so that one could open a protected PDF.

However what is interesting here is that if a user goes to inspect the properties of the app to be installed, a cursory glance will show that, according to AppX Installer, it is signed by a trusted publisher and the publisher details look legitimate. Its not unless you click on the Trusted App details link that one will see that something looks odd (assuming of course the user hasn’t already found the request for downloading a PDF viewer for viewing a sent PDF file suspicious).

Microsoft fixed this bug by disabling the ms-appinstaller:// URL entirely to prevent it from being abused for these types of attacks, however it is also recommended that the Prevent non-admin users from installing packaged Windows apps setting be set to prevent non-admin users from being able to install packaged Windows apps, which should prevent variants of this attack from being exploitable in your environment. More information on these and other mitigations can be found under the Workarounds section at

Technical Analysis

Whilst this was originally considered a DoS vulnerability, new evidence has turned up as noted at and later at by Márcio Almeida that is possible to bypass the allowedLdapHost and allowedClasses checks in Log4J 2.15.0. to achieve RCE by simply modifying following PoC slightly:


This bypass works due to the call chain calling getHost() returning the value before the # sign as the real host, which will return However the actual JDNI/LDAP resolver will end up using the full hostname string, so provided you can get it to respond to the weird hostname, you should be good.

Further investigation however shows that this vulnerability is mostly mitigated by a few factors as noted by Kevin Beaumont at and in a further Twitter thread by @buherator at

Specifically the following restrictions apply:

  1. The vulnerability only applies in a nondefault configuration. Specifically %m{lookups} need to be enabled in the message log. On 2.15.0 message lookups come disabled by default, however previous versions may come shipped with this enabled by default.
  2. So far reliable RCE has only been demonstrated on MacOS, and most people aren’t going to be running critical apps on this device.
  3. Whilst it is possible to query the weird name LDAP name on other hosts, it appears, according to the thread at, that the Java resolver enforces restrictions that prevent the name from being resolved. Whilst is is possible to get around this, as noted at, it requires the DNS provider on the target system being set to a non-default provider.

It should be noted that developments on this are still ongoing so its likely the situation could change, however this is the latest info I have on this as of the evening of December 17th, 2021. Due to the restrictions I’m rating exploitability as very low as a lot of things must be true from the sounds of it for this to be exploitable, however if it is exploitable the impact is very high and is the same as the log4shell exploit.

It should be noted despite all this that there exists other issues within Log4j versions prior to 2.16 such as Praetorian’s demonstration of sensitive information exfiltration as noted at Therefore whilst this particular vulnerability may not be as impactful there are plenty of other reasons why you should upgrade to 2.16 or later of log4j if you haven’t already.

Technical Analysis

This is an interesting vulnerability in the Ai-Bolit AV scanner functionality of CloudLinux Inc Imunify360 running Ai-Bolit prior to AI-Bolit 31.1.2-1, Interestingly whilst it was stated that 30.8.8-1, 30.8.9-1, 30.10.3-1, 31.0.3-1, and 31.1.1-1 were affected, in my testing the Ubuntu dpkg files that were available on CloudLinux’s servers only contained versions 30.10.3-1 and later, and surprisingly only 30.10.3-1 actually contained the vulnerability. All later versions were found to be patched. Older versions were not found on the server so it was not possible to obtain a copy of these affected versions, however it is likely they were also affected and the patch was either introduced with 31.10.3-1 or was introduced with 31.1.2-1 and then backported to versions 30.10.3-1 and later.

Note that the software used to be at as ai-bolit_30.10.3-1_amd64.deb however it appears it has since been removed. If you need a copy of this file please feel free to reach out.

Working from the original PoC at we can see that the vulnerability occurs due to an unserialize() call within deobfuscateDecodedFileGetContentsWithFunc($str, $matches) where the line $resCode = implode(' ', @unserialize(base64_decode($matches[5]))); is executed, which first base64 decodes the 5th match, which contains a subset of the attacker controlled file that is being scanned, Base64 decodes it, and then passes it, unchecked, into a call to unserialize().

Tracing back we can see that there is a regex in the Obfuscator class associated with the ID decodedFileGetContentsWithFunc(). This is the regex that is used to scan the file, and then if any patterns are found that match this regex, then deobfuscateDecodedFileGetContentsWithFunc() is called to deobfuscate the file.


After a lot of time spent manually going through the regex using I was able to recreate a file that would trigger the regex and result in deserialization:

function func1($param){ $asdf = "cool";$asc = str_split($foobar);$word = array_flip($asc);$food = 0;$cored="";$bored=preg_replace("asdf", "", $deda);do {$asdf = $asdf[$acfd[$foa++]];$asdf = $asdf[$acfd[$foa++]];$asdf = $asdf[$acfd[$foa++]];$asdf = $asdf[$acfd[$foa++]];$coolio=($joko << 2) | ($foko >> 4);$cood = (($aed & 15) << 4) | ($ave >> 2);$aesd = (($ke & 3) << 6) | $hes;$hec = $hek . chr($jok);if ($asdf != 64) {$foobd = $coor . chr($foj);}if ($hdo != 64) {$fed = $asdf . chr($ase);}} while ($asdfas < strlen($ddhdh));return $asdfe;} function func2(){$corlan = @file_get_contents(asdfasdf()); $variable1 = "INSERTTHEPAYLOADHEREBASE64ENCODED"; $variable1 = @unserialize(func1($variable1)); function func3($faccc=NULL){foreach (func2() as eval($fjdjd);}}} func3();

Note that most names are junk however anything with variable1 or func1 is specifically named as such (the string “variable” or “func” followed by a number) as they need to be the same name everywhere they are used. This is due to the regex using some of the results from earlier checks later on in its code, so the names of these functions or variables must remain the same otherwise the regex won’t match.

Now whilst deserialization attacks can result in RCE, arbitrary file deletion, or otherwise remember that it really depends what classes are available to the end user. In my experiments I found the following classes were available when the unserialize() call was made:


Unfortunately of these I was mainly only able to find cases where deserializing an object would cause file deletion. In cases where file creation was possible, it was either in a fixed location with a nonexecutable extension, or more often than not the content of the file would be a fixed string which wasn’t useful for the purposes of exploitation.

The most promising class appeared to be CloudAssistedFiles which could cause a CURL request to be made, however it appears that the URL, as well as the contents of the request could not be controlled, so unfortunately there would not be any way to retrieve data from the server from what I could tell.

Arbitrary file deletion can be achieved via the Logger class and the $log_file parameter of the __construct function.

At the end of the research I was not able to form a useful payload for this vulnerability. In my opinion, given what I saw so far, the most likely possibility for exploitation would be that someone used the exploit chain to delete something like .htaccess and then abuse that to bypass a file upload filter or similar.

However this is highly dependent on the application and a variety of other factors, vs this being a bug that can be installed purely by virtue of having Ai-Bolit AV scanner installed.

A final important note is that CloudLinux Inc Imunify360 is, by default, configured to check for updates automatically once daily. This means its very likely that most installations in the wild are up to date, and I personally noticed this when trying to find servers with Imunify360 installed, as most of these servers were running up to date versions of Imunify360 or one of its respective components.

Technical Analysis

An unauthenticated command injection bug in WD My Book Live and WD My Book Live Duo devices that gives root level access to the device and all the data stored on it. This has been actively exploited in the wild and there is no plan from the manufacture to fix this bug since it only affects WD My Book Live devices which they state where introduced to the market in 2010 and recieved their final update in 2015. Your best bet is to migrate your data and then get rid of this device somehow.

It is also important to note that this auth bypass occurs due to a refactoring of the authentication code where appropriate access checks were not applied. You can read more on this at

Technical Analysis

From what I can tell this is likely a relatively easy exploit given that one resets the entire device via an unauthenticated request. This essentially allows the attacker to reset the device and erase all data on the storage device without any authentication at all. This could be used to ransom off targets and threaten to destroy their data if they don’t comply, then use the bug to exploit the storage devices and wipe all their data if they didn’t pay up.

Of less value to attackers since they would likely just end up erasing a client’s data however given how protective of data most companies are, I can imagine this most likely being used in ransom schemes as mentioned above. Less likely to be used to actually steal data unless by resetting the device you can somehow get other devices to resync the data to the drive and have the attacker now have full access to the box.

Otherwise its good to note this has been exploited in the wild and there is no plan to patch this bug since the firmware went out of date in 2015 and the manufacture has stopped updating the firmware for this device with no plans to supply any changes even for security related issues. Your best bet is to migrate your data and get a more modern device. More info on the refactoring of the code that lead to this bug can be found at

  • Attacker Value
  • Exploitability
Technical Analysis

This is an interesting bug that allows one to exploit a bug in the mod_proxy add on module of Apache HTTP server 2.4.48 and earlier to perform a server side request forgery (SSRF) attack and force the server to make requests on the attacker’s behalf. It was discovered by the Apache HTTP security team whilst analyzing CVE-2021-36160.

This is already being exploited in the wild as noted at with evidence that in at least one case, attackers were able to obtain hash values of user credentials from victim systems via this attack.

There is also evidence that this might affect Cisco products that bundle Apache HTTP Servers with them as noted at however investigation is still ongoing on this matter by Cisco at the time of writing, with the only product confirmed as not being vulnerable listed as Cisco Virtual Topology System.

In general SSRF vulnerabilities are very valuable to attackers as they not only allow access to the internal network of a target, but they can disguise their requests as coming from a legitimate web server that the network trusts. This often means that there is more trust placed in these requests which sometimes means less security checks are placed on them.

It is also important to note that whilst this vulnerability does require the mod_proxy module to be loaded, this is an very common module for most servers and so it is likely to be loaded, increasing the likelihood that an outdated Apache server is vulnerable to this attack.

In short, this bug is being exploited in the wild, allows unauthenticated attackers a way to make trusted requests to internal endpoints, and has been used to steal hashed credentials in a real world attack. Whilst true impact will likely depend on the way the target network is configured and what vulnerabilities are on the systems accessible via the target web server, this vulnerability alone is already providing attackers a lot more insight into a target network through a very common server setup, and therefore should be patched as soon as possible.

Technical Analysis

The patch bypass for this vulnerability is now being exploited in the wild as noted at I have not labeled this bug as exploited in the wild though as the code noted below by @kevthehermit is an exploit for a variant of this bug, not this bug itself, however it is important to note that the bugs are related and no patch exists yet for the variant at the time of writing (November 24th 2021).