**What is the version information for this release?**

Microsoft Edge Version

Date Released

Based on Chromium Version

97.0.1072.55

1/6/2022

97.0.4692.71

CVE-2022-0114: Chromium: CVE-2022-0114 Out of bounds memory access in Web Serial

CVE-2022-0106: Chromium: CVE-2022-0106 Use after free in Autofill

CVE-2022-0105: Chromium: CVE-2022-0105 Use after free in PDF

CVE-2022-0102: Chromium: CVE-2022-0102 Type Confusion in V8 

In lighttpd 1.4.46 through 1.4.63, the mod_extforward_Forwarded function of the mod_extforward plugin has a stack-based buffer overflow (4 bytes), as demonstrated by remote denial of service (daemon crash).

I uploaded the exp by mistake, please delete it in time

*   **File** deleted (_exp.py_)

*   **Subject** changed from _Security - lighttpd mod\_extforward plugin has stack overflow vulnerability_ to _lighttpd mod\_extforward plugin has out-of-bounds (OOB) write of 4-byte -1_
*   **Description** updated (diff)
*   **Status** changed from _New_ to _Patch Pending_
*   **Target version** changed from _1.4.xx_ to _1.4.64_

You are correct that there is an out-of-bounds write on the stack.  
However, this out-of-bounds write is not controlled by the attacker.  
The value that is written out-of-bounds after the end of offsets\[\] is -1

However, with the default lighttpd build with `gcc -O2`, I was unable to  
trigger a crash in lighttpd on amd64 (64-bit) or on i686 (32-bit).

As with your prior posts, I think your test toolchain is configured  
with a stack canary which crashes when an out-of-bounds read or write  
is detected, which is fine for your research, but not necessarily a  
reflection of real-world impact. When mod\_extforward.c is compiled with  
`-fstack-protector-all -fstack-protector-strong`, I was able to trigger  
a crash in lighttpd on i686 (32-bit), but not amd64 (64-bit), using the  
reproducer (exp.py) you had provided.

Also, the scenario in which this occurs is not enabled by default in lighttpd.

*   First, the user must be using mod\_extforward. (not default)
*   Second, the user must explicitly configure `extforward.headers`  
    to contain "Forwarded" (not default)
*   Third, the user must have configured mod\_extforward to trust the  
    upstream proxy server which proxied the request to lighttpd,  
    and from which lighttpd is receiving the "Forwarded" header.  
    This upstream proxy must allow and use this unusual "Forwarded"  
    header.

Your statement that this issue affects lighttpd 1.4.41-1.4.63 is incorrect.  
Support for the "Forwarded" header was added in lighttpd 1.4.46.  
https://redmine.lighttpd.net/issues/2703  
I have updated your original post.

Given this initial assessment (not yet complete), I have changed the  
the wording of this issue to tone it down from vulnerability to OOB write.  
There is a bug that will be fixed, but unless further information comes to  
light, this does not appear to have security implications for default usage  
of lighttpd. Please help me determine in which scenarios and platforms  
this might have an impact.

*   **Subject** changed from _lighttpd mod\_extforward plugin has out-of-bounds (OOB) write of 4-byte -1_ to _mod\_extforward plugin has out-of-bounds (OOB) write of 4-byte -1_

gstrauss wrote in #note-3:

> You are correct that there is an out-of-bounds write on the stack.  
> However, this out-of-bounds write is not controlled by the attacker.  
> The value that is written out-of-bounds after the end of offsets\[\] is -1
> 
> However, with the default lighttpd build with `gcc -O2`, I was unable to  
> trigger a crash in lighttpd on amd64 (64-bit) or on i686 (32-bit).
> 
> As with your prior posts, I think your test toolchain is configured  
> with a stack canary which crashes when an out-of-bounds read or write  
> is detected, which is fine for your research, but not necessarily a  
> reflection of real-world impact. When mod\_extforward.c is compiled with  
> `-fstack-protector-all -fstack-protector-strong`, I was able to trigger  
> a crash in lighttpd on i686 (32-bit), but not amd64 (64-bit), using the  
> reproducer (exp.py) you had provided.
> 
> Also, the scenario in which this occurs is not enabled by default in lighttpd.
> 
> *   First, the user must be using mod\_extforward. (not default)
> *   Second, the user must explicitly configure `extforward.headers`  
>     to contain "Forwarded" (not default)
> *   Third, the user must have configured mod\_extforward to trust the  
>     upstream proxy server which proxied the request to lighttpd,  
>     and from which lighttpd is receiving the "Forwarded" header.  
>     This upstream proxy must allow and use this unusual "Forwarded"  
>     header.
> 
> Your statement that this issue affects lighttpd 1.4.41-1.4.63 is incorrect.  
> Support for the "Forwarded" header was added in lighttpd 1.4.46.  
> https://redmine.lighttpd.net/issues/2703  
> I have updated your original post.
> 
> Given this initial assessment (not yet complete), I have changed the  
> the wording of this issue to tone it down from vulnerability to OOB write.  
> There is a bug that will be fixed, but unless further information comes to  
> light, this does not appear to have security implications for default usage  
> of lighttpd. Please help me determine in which scenarios and platforms  
> this might have an impact.

I'm using the ubuntu 20.04 default configuration, where canary is turned on by default

povcfe-bug wrote in #note-5:

> gstrauss wrote in #note-3:
> 
> > You are correct that there is an out-of-bounds write on the stack.  
> > However, this out-of-bounds write is not controlled by the attacker.  
> > The value that is written out-of-bounds after the end of offsets\[\] is -1
> > 
> > However, with the default lighttpd build with `gcc -O2`, I was unable to  
> > trigger a crash in lighttpd on amd64 (64-bit) or on i686 (32-bit).
> > 
> > As with your prior posts, I think your test toolchain is configured  
> > with a stack canary which crashes when an out-of-bounds read or write  
> > is detected, which is fine for your research, but not necessarily a  
> > reflection of real-world impact. When mod\_extforward.c is compiled with  
> > `-fstack-protector-all -fstack-protector-strong`, I was able to trigger  
> > a crash in lighttpd on i686 (32-bit), but not amd64 (64-bit), using the  
> > reproducer (exp.py) you had provided.
> > 
> > Also, the scenario in which this occurs is not enabled by default in lighttpd.
> > 
> > *   First, the user must be using mod\_extforward. (not default)
> > *   Second, the user must explicitly configure `extforward.headers`  
> >     to contain "Forwarded" (not default)
> > *   Third, the user must have configured mod\_extforward to trust the  
> >     upstream proxy server which proxied the request to lighttpd,  
> >     and from which lighttpd is receiving the "Forwarded" header.  
> >     This upstream proxy must allow and use this unusual "Forwarded"  
> >     header.
> > 
> > Your statement that this issue affects lighttpd 1.4.41-1.4.63 is incorrect.  
> > Support for the "Forwarded" header was added in lighttpd 1.4.46.  
> > https://redmine.lighttpd.net/issues/2703  
> > I have updated your original post.
> > 
> > Given this initial assessment (not yet complete), I have changed the  
> > the wording of this issue to tone it down from vulnerability to OOB write.  
> > There is a bug that will be fixed, but unless further information comes to  
> > light, this does not appear to have security implications for default usage  
> > of lighttpd. Please help me determine in which scenarios and platforms  
> > this might have an impact.
> 
> I'm using the ubuntu 20.04 default configuration, where canary is turned on by default

The reason why 64-bit programs can't crash is that sse 16-bit alignment, when closing intel sse, 64-bit programs will also crash, so please make sure that mips, arm and other architecture programs will not trigger a crash.

So compiling 32-bit lighttpd within an operating system with a higher gcc version, or compiling and using lighttpd with an architecture that does not support sse 16-bit byte alignment, will result in a denial of service

gstrauss wrote in #note-8:

> > So compiling 32-bit lighttpd within an operating system with a higher gcc version, or compiling and using lighttpd with an architecture that does not support sse 16-bit byte alignment, will result in a denial of service
> 
> You seem to be overlooking the prerequisites to reaching the bug. Case in point, I wrote:
> 
> > > *   Third, the user must have configured mod\_extforward to trust the  
> > >     upstream proxy server which proxied the request to lighttpd,  
> > >     and from which lighttpd is receiving the "Forwarded" header.  
> > >     This upstream proxy must allow and use this unusual "Forwarded"  
> > >     header.
> 
> For someone to want to configure lighttpd this way, they must be using a proxy which supports "Forwarded". Do you know of real-world use in popular CDNs? Most CDNs and cloud providers have their own custom fields for X-Forwarded-For.
> 
> I took a quick look and Cloudflare does not currently support Forwarded.  
> https://community.cloudflare.com/t/support-for-http-forwarded-header-as-a-replacement-for-x-forwarded-for/320943  
> Nor does HAProxy (where the HAProxy "PROXY" protocol is often preferred)  
> https://github.com/haproxy/haproxy/issues/575
> 
> I did find that "Forwarded" is implemented in  
> https://microsoft.github.io/reverse-proxy/articles/transforms.html#forwarded  
> though a developer noted it is not enabled by default  
> (https://github.com/dotnet/aspnetcore/issues/5978#issuecomment-668013246)  
> and "Forwarded" is implemented in  
> https://github.com/gorilla/handlers/blob/master/proxy\_headers.go
> 
> Please keep in mind that my questions here and above are to help gauge potential impact of the bug.
> 
> Thus far, based on what I have posted here and above, I am confident that the bug is not reachable in **common** use scenarios of lighttpd mod\_extforward.

I noticed that "https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs\_ModExtForward" mentions a custom setting for "Forwarded", which is not really the default configuration, but I mean that for users with such a configuration, remote denial of service is possible.

*   **File** header.png header.png added

![](https://redmine.lighttpd.net/attachments/thumbnail/2160)

![](https://redmine.lighttpd.net/attachments/download/2160/header.png)

This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

gstrauss wrote in #note-11:

> This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> 
> My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

I agree with you in the comment above that he will not be triggered by default

gstrauss wrote in #note-11:

> This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> 
> My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

I hope you will listen to me carefully, you said he will not be triggered by default, I agree. Also you said that canary must be turned on to trigger a crash, I told you that canary is turned on by default in higher versions of gcc, and that crashes are possible for system architectures that do not have SSE turned on.

povcfe-bug wrote in #note-12:

> gstrauss wrote in #note-11:
> 
> > This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> > 
> > My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.
> 
> I agree with you in the comment above that he will not be triggered by default

Please respect contributors who find problems and submit patches

> Please respect contributors who find problems and submit patches

I appreciate that you have taken the time to find this and to post it so that it can be fixed. Thank you.

Above, I wrote:

> > This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> > 
> > My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

Please help me to understand why you feel disrespected by these grounded statements. Impact analysis is an important part of bug and security triage.

gstrauss wrote in #note-15:

> > Please respect contributors who find problems and submit patches
> 
> I appreciate that you have taken the time to find this and to post it so that it can be fixed. Thank you.
> 
> Above, I wrote:
> 
> > > This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> > > 
> > > My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.
> 
> Please help me to understand why you feel disrespected by these grounded statements. Impact analysis is an important part of bug and security triage.

I don't think you've just listened carefully to my analysis, and there are differences between our two concerns. Impact exclusion is indeed a very important aspect, and I agree with your analysis above

> > This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

> I don't think you've just listened carefully to my analysis, and there are differences between our two concerns.

Would you please describe your concerns in more detail?

Your post is less than 5 hours old and I have spent a considerable amount of time reviewing, reproducing, and analyzing the potential impact, and have tried to be explicit in my posts that these are the steps I am taking. If you feel that I am giving it short thrift, then please describe your expectations in more detail.

gstrauss wrote in #note-17:

> > > This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> 
> > I don't think you've just listened carefully to my analysis, and there are differences between our two concerns.
> 
> Would you please describe your concerns in more detail?
> 
> Your post is less than 5 hours old and I have spent a considerable amount of time reviewing, reproducing, and analyzing the potential impact, and have tried to be explicit in my posts that these are the steps I am taking. If you feel that I am giving it short thrift, then please describe your expectations in more detail.

Sorry, my narrative above was just to show you that users using this non-default configuration can trigger crashes with the default compile option. I appreciate your work, and your attention to this issue, and I apologize.

Yes, for systems and distros which enable the canary by default, and if the prerequisites to reach the bug are met, then the bug will trigger a crash.

Please attach a patch (e.g. output from `git format-patch`) with the patch in your original post and how you'd like to be credited. The patch looks good, and I'll need to edit the commit message a bit, but will try to preserve what you'd like to include.

It's late here and I'll return to this tomorrow.

I have applied for a cve id, please trace

You did not include a commit message in the attachment. Please see the lighttpd git history for how I credit contributors and let me know if you would like any different.

> I have applied for a cve id, please trace

What do you mean by "please trace"? Is that an incomplete sentence?

I have a feeling that you are disappointed that my analysis indicates that this bug is low severity, as its prevalence in production is likely to be rare and specialized. Even when the bug is reachable, I do not believe it exploitable beyond triggering a crash. I will dispute the CVE if you represent the bug otherwise.

gstrauss wrote in #note-22:

> You did not include a commit message in the attachment. Please see the lighttpd git history for how I credit contributors and let me know if you would like any different.
> 
> > I have applied for a cve id, please trace
> 
> What do you mean by "please trace"? Is that an incomplete sentence?
> 
> I have a feeling that you are disappointed that my analysis indicates that this bug is low severity, as its prevalence in production is likely to be rare and specialized. Even when the bug is reachable, I do not believe it exploitable beyond triggering a crash. I will dispute the CVE if you represent the bug otherwise.

I applied for cve with a remote denial of service error type, which I think is reasonable, emm. I would like to know if you agree.

this is the new patch  

    From 8a91fd45f7f31707a876492b13c0f46845626727 Mon Sep 17 00:00:00 2001
    From: povcfe <povcfe@qq.com>
    Date: Wed, 5 Jan 2022 12:44:34 +0000
    Subject: [PATCH] [mod_extforward] fix out-of-bounds (OOB) write of 4-byte -1
    
    (thx povcfe)
    ---
     src/mod_extforward.c | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    diff --git a/src/mod_extforward.c b/src/mod_extforward.c
    index 733231fd..8dbdfad9 100644
    --- a/src/mod_extforward.c
    +++ b/src/mod_extforward.c
    @@ -715,7 +715,7 @@ static handler_t mod_extforward_Forwarded (request_st * const r, plugin_data * c
             while (s[i] == ' ' || s[i] == '\t') ++i;
             if (s[i] == ';') { ++i; continue; }
             if (s[i] == ',') {
    -            if (j >= (int)(sizeof(offsets)/sizeof(int))) break;
    +            if (j >= (int)((sizeof(offsets)/sizeof(int)) - 1)) break;
                 offsets[++j] = -1; /*("offset" separating params from next proxy)*/
                 ++i;
                 continue;
    --
    2.25.1

CVE-2022-22707: Bug #3134: mod_extforward plugin has out-of-bounds (OOB) write of 4-byte -1 - Lighttpd

Foxit PDF Reader and PDF Editor before 11.1 on macOS allow remote attackers to execute arbitrary code via getURL in the JavaScript API.

CVE-2021-45980: Security Bulletins | Foxit Software

Utilizing existing Microsoft features for offensive operations is very common during red team assessments as it provides the opportunity to blend in with the environment… 
Continue reading → Domain Persistence – AdminSDHolder

Utilizing existing Microsoft features for offensive operations is very common during red team assessments as it provides the opportunity to blend in with the environment and stay undetected. Microsoft introduced “_AdminSDHolder_” active directory object to protect high privilege accounts such as domain admins and enterprise admins from unintentional modifications of permissions as it is used as security template. Active directory retrieves the ACL of the “_AdminSDHolder_” object periodically (every 60 minutes by default) and apply the permissions to all the groups and accounts which are part of that object. This means that during red team operations even if an account is detected and removed from a high privileged group within 60 minutes (unless it is enforced) these permissions will be pushed back.

In the event that a domain has been compromised a standard user account can be added into the access control list of the “_AdminSDHolder_” in order to establish domain persistence. This user will acquire “GenericAll” privileges which is the equivalent of the domain administrator. This technique is not new as it has been presented initially by Sean Metcalf during DerbyCon in 2015. The implementation of the attack is trivial from an elevated PowerShell console by executing the following PowerView module:

    Add-ObjectAcl -TargetADSprefix 'CN=AdminSDHolder,CN=System' -PrincipalSamAccountName pentestlab -Verbose -Rights All

AdminSDHolder – Modification

After 60 minutes the changes in the permissions will be applied and the module “_Get-ObjectAcl_” can be used to validate that the user “_pentestlab_” has “_GenericAll_” active directory rights.

    Get-ObjectAcl -SamAccountName "Domain Admins" -ResolveGUIDs | ?{$_.IdentityReference -match 'pentestlab'}

AdminSDHolder – GenericAll Privileges

Changes in ACL will propagate automatically after 60 minutes. This is due to the Security Descriptor propagator (SDProp) process that runs every 60 minutes on the Principal Domain Controller (PDC) emulator and populates the access control list with the security permissions that exist in the AdminSDHolder for groups and accounts. However, these could be forced by modifying the DN as it can be seen below using the “_ldp.exe_” utility.

AdminSDHolder – Modify DN

Alternatively modification of a specific registry key on the domain controller can reduce the time interval of the SDProp to 3 minutes (12c hexadecimal value). It should be noted that Microsoft doesn’t recommend the modification of this setting as this might cause performance issues in relation to LSASS process across the domain.

    REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 300

From the perspective of Active Directory it is visible that the user “_pentestlab_” has been added at the “_AdminSDHolder_” object by looking on its Properties.

AdminSDHolder – Properties

Groups and accounts which are part of the “_AdminSDHolder_” container will have the “_adminCount_” attribute set to 1. This flag indicates that permissions from that container will be copied in 60 minutes across the domain even if privileges are modified.

AdminSDHolder – adminCount

Since the user has the required permissions it can be added to the “_Domain Admins_” group.

    net group "domain admins" pentestlab /add /domain

Add user to Domain Admins Group

Executing the command below will verify that the domain controller is now accessible and domain persistence has been established.

    dir \\10.0.0.1\c$

AdminSDHolder – DC Access

**References**

*   https://adsecurity.org/?p=1906
*   https://www.harmj0y.net/blog/redteaming/abusing-active-directory-permissions-with-powerview/
*   https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/how-to-abuse-and-backdoor-adminsdholder-to-obtain-domain-admin-persistence

**Post navigation**

Domain Persistence – AdminSDHolder

Potential product security bypass vulnerability in McAfee Application and Change Control (MACC) prior to version 8.3.4 allows a locally logged in attacker to circumvent the application solidification protection provided by MACC, permitting them to run applications that would usually be prevented by MACC. This would require the attacker to rename the specified binary to match name of any configured updater and perform a specific set of steps, resulting in the renamed binary to be to run.

**First Published:** December 30, 2021

**Product:**

**Impacted Versions:**

**CVE ID:**

**Impact of Vulnerabilities:**

**Severity Ratings:**

**CVSS v3.1  
Base/Temporal Scores:**

McAfee Application and Change Control (MACC)

Prior to 8.3.4

CVE-2021-31833

CWE-269 – Improper Privilege Management

High

7.1 / 6.4

 **Recommendations:**

Install or update to MACC 8.3.4

 **Security Bulletin Replacement:**

None

 **Location of updated software:**

Product Downloads site

To receive email notification when this Security Bulletin is updated, click **Subscribe** on the right side of the page. You must be logged on to subscribe.

**Article contents:**

*   Vulnerability Description
*   Remediation
*   Workaround
*   Frequently Asked Questions (FAQs)
*   Resources
*   Disclaimer

**Vulnerability Description**  
To exploit this the attacker would need to copy files around the target machine and rename them. They would then need to follow some specific steps to run the renamed files.  

**CVE-2021-31833**  
Potential product security bypass vulnerability in McAfee Application and Change Control (MACC) prior to version 8.3.4 allows a locally logged in attacker to circumvent the application solidification protection provided by MACC, permitting them to run applications that would usually be prevented by MACC. This would require the attacker to rename the specified binary to match name of any configured updater and perform a specific set of steps, resulting in the renamed binary to be to run.  
MITRE CVE-2021-31833  
NIST CVE-2021-31833  
**Remediation**  
To remediate this issue, go to the Product Downloads site, and download the applicable product update file:

**Product**

**Version**

**Type**

**Release Date**

MACC

8.3.4

Update

December 28, 2021

 

**Download and Installation Instructions**  
For instructions to download product updates and hotfixes, see: KB56057 - How to download Enterprise product updates and documentation. Review the Release Notes and the Installation Guide for instructions on how to install these updates. All documentation is available at our Product Documentation site.  
**Workaround**  
McAfee Enterprise strongly recommends installing the updated version of MACC.

If you're not able to update, you can change the configuration through ePO to mitigate this issue.

**WARNING:** This might lead to denial of execution to Microsoft and McAfee Enterprise signed binaries if they're not whitelisted.

1.  Log on to the ePO console.
2.  Navigate to **Policy Catalog**, **Solidcore**, **Configuration (Client)**, **McAfee Default (Read Only)**.
3.  Duplicate the **McAfee Default (Read Only)** policy.
4.  Open the copy you just created.
5.  Navigate to **Certificate configuration**.
6.  Change the value of **Enable VTP trust check** to **0** (from 1).
7.  Save the policy.
8.  Apply the policy to endpoints.

When you do update to the recommended version, you should undo the above change.  
**Frequently Asked Questions (FAQs)**  
**How do I know if my product is vulnerable or not?**

For endpoint products:

Use the following instructions for endpoint or client-based products:

1.  Right-click the McAfee tray shield icon on the Windows taskbar.
2.  Select **Open Console**.
3.  In the console, select **Action Menu**.
4.  In the Action Menu, select **Product Details**. The product version displays.

**What is CVSS?**  
Common Vulnerability Scoring System (CVSS) is the result of the National Infrastructure Advisory Council's effort to standardize a system of assessing the criticality of a vulnerability. This system offers an unbiased criticality score between 0 and 10 that customers can use to judge how critical a vulnerability is and plan accordingly. For more information, visit the CVSS website.

  When calculating CVSS scores, McAfee Enterprise has adopted a philosophy that fosters consistency and repeatability. Our guiding principle for CVSS scoring is to score the exploit under consideration by itself. We consider only the immediate and direct impact of the exploit under consideration. We don’t factor into a score any potential follow-on exploits that might be made possible by the successful exploitation of the issue being scored.

  **What are the CVSS scoring metrics?**

**CVE-2021-31833:**

**Base Score**

**7.1**

Attack Vector (AV)

Local (L)

Attack Complexity (AC)

Low (L)

Privileges Required (PR)

Low (L)

User Interaction (UI)

None (N)

Scope (S)

Unchanged (U)

Confidentiality (C)

None (N)

Integrity (I)

High (H)

Availability (A)

High (H)

**Temporal Score (Overall)**

**6.4**

Exploitability (E)

Proof-of-Concept (P)

Remediation Level (RL)

Official Fix (O)

Report Confidence (RC)

Confirmed (C)

 

**NOTE:** This CVSS version 3.1 vector was used to generate this score.

**Where can I find a list of all Security Bulletins?**  
All Security Bulletins are published on our external PSIRT website. To see Security Bulletins for McAfee Enterprise products on this website, click **Enterprise Security Bulletins**. Security Bulletins are retired (removed) once a product is both End of Sale and End of Support (End of Life).

  **How do I report a product vulnerability to McAfee Enterprise?**  
If you have information about a security issue or vulnerability with a McAfee Enterprise product, go to the PSIRT website, click **Report a Security Vulnerability**, and follow the instructions.

  **How does McAfee Enterprise respond to this and any other reported security flaws?**  
Our key priority is the security of our customers. If a vulnerability is found within any McAfee Enterprise software or services, we work closely with the relevant security software development team to ensure the rapid and effective development of a fix and communication plan.

  McAfee Enterprise only publishes Security Bulletins if they include something actionable such as a workaround, mitigation, version update, or hotfix. Otherwise, we would simply be informing the hacker community that our products are a target, putting our customers at greater risk. For products that are updated automatically, a non-actionable Security Bulletin might be published to acknowledge the discoverer.

  View our PSIRT policy on the PSIRT website by clicking **About PSIRT**.  
**Resources**

*   If you are a registered user, type your User ID and Password, and then click **Log In**.
*   If you are not a registered user, click **Register** and complete the fields to have your password and instructions emailed to you.

**Disclaimer**  
The information provided in this Security Bulletin is provided as is without warranty of any kind. McAfee Enterprise disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall McAfee Enterprise or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if McAfee Enterprise or its suppliers have been advised of the possibility of such damages. Some states don’t allow the exclusion or limitation of liability for consequential or incidental damages so the preceding limitation may not apply.

  Any future product release dates mentioned in this Security Bulletin are intended to outline our general product direction, and they shouldn’t be relied on in making a purchasing decision. The product release dates are for information purposes only, and may not be incorporated into any contract. The product release dates aren’t a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for our products remains at our sole discretion and may be changed or canceled at any time.

CVE-2021-31833: Security Bulletin - Application and Change Control update fixes one vulnerability (CVE-2021-31833)

Microsoft SharePoint Elevation of Privilege Vulnerability.

Tag

#microsoft