Microsoft Starts 2022 with 97 CVEs in January Patch Tuesday

Microsoft began the year by publishing fixes for nearly a century of vulnerabilities, nine of which were rated critical and six of which were publicly disclosed.

The Windows OS updates issued this month will fix all of the known bugs, according to Ivanti VP of product management, Chris Goettl.

“While there are no known exploited vulnerabilities this month, the six publicly disclosed vulnerabilities may warrant more immediate attention as they could have exposed proof-of-concept code or other details that can give adversaries additional details to develop an exploit,” he warned.

These include: CVE-2022-21839, a denial of service vulnerability in the Windows event tracing discretionary access control list; an elevation of privilege flaw in Windows user profile service (CVE-2022-21919); and a Windows certificates spoofing vulnerability (CVE-2022-21836).

The remaining three publicly disclosed flaws are remote code execution bugs in Windows Security Center API (CVE-2022-21874), libarchive (CVE-2021-36976) and open source curl (CVE-2021-22947).

According to Automox, this month’s Patch Tuesday has the highest number of critical CVEs since July 2021.

There’s plenty more to keep sysadmins busy. Mozilla resolved 18 CVEs, including nine rated critical in three updates, impacting Mozilla Thunderbird, Firefox and Firefox ESR. Adobe issued five updates resolving 41 vulnerabilities, 22 of which are rated as critical.

There’s also more to come, with Oracle’s quarterly Critical Patch Update set to land next week.

All of this comes as organizations continue to hunt for vulnerable Log4j instances in their IT ecosystem, many of which may be hidden by complex Java dependencies.

“Organizations that were able to respond quickly found that truly understanding their exposure required rolling up their sleeves. They quickly assessed their internal development teams for use of Log4j and their vendor risk management process to determine what vendors they were consuming solutions from and assessing each to determine if they were exposed,” explained Goettl.

“As an additional step, security teams also utilized a variety of custom scanners purpose-built to scan for the Log4j binaries. This is crucial given Log4j was buried many cases in a few layers of JAR files which was throwing many vulnerability scanners off.