MSRC Blog

If you follow the CVE link included: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53136 It would seem this was patched in the Aug 12 security patch rollout.

> With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. There is a mountain of evidence (two examples follow) that this is not true. Roughly two-thirds of serious security bugs in large C++ products are still memory-safety violations. (1) https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-systems-progra… (2) https://www.chromium.org/Home/chromium-security/memory-safety/

The "majority of CVEs" isn't a great metric, since (1) anybody can file a CVE, and (2) CNAs can be tied to vendors, who are incentivized to pre-filter CVEs or not issue CVEs at all for internal incidents. Thankfully, we have better data sources. Chromium estimates that 70% of serious security bugs in their codebases stem from memory unsafety[1], and MSRC estimates a similar number for Microsoft's codebases[2]. (General purpose programming languages can't prevent logic bugs. However, I would separately argue that idiomatic Rust programs are less likely to experience classes of logic bugs that are common in C and C++ programs, in part because strong type systems can make invalid states unrepresentable.) [1]: https://www.chromium.org/Home/chromium-security/memory-safety/ [2]: https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-systems-progra…

From the source: https://msrc.microsoft.com/blog/2024/03/update-on-microsoft-actions-fo…

>his son is learning Rust and that it is better I'm hoping this was sarcasm. This recommendation was in the form of a report by the Office of the National Cyber Director (ONCD) in the White House. I would suspect it had more thought to it than you're suggesting. I think this quote from the article is quite useful: "Recent studies from Microsoft and Google have found that about 70 percent of all security vulnerabilities are caused by memory safety issues." Which the article cites [1] [2] There is validity to their argument on the source of security vulnerabilities. [1] https://www.chromium.org/Home/chromium-security/memory-safety/ [2] https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-s…

Read also the follow-up post, "First steps in CHERIoT Security Research" https://msrc.microsoft.com/blog/2023/02/first-steps-in-cheriot-securit… Ironically, the future of secure computing is bringing back memory tagging.

MS publishes Azure IP ranges[1] so it should be trivial to check if the attack originates from those or something else. MS also has abuse contact exactly for this purpose[2]. I have no experience what their response is there, but probably worth a shot anyways. [1] https://www.microsoft.com/en-us/download/details.aspx?id=56519 [2] https://msrc.microsoft.com/report/abuse

> Linearizability is just not as important as some people make it out to be. That's my entire point. Start with strong models and weaken when you decide you need it. Thus rule out entire classes of bugs for 99% of your code and closely scrutinize the 1% with weakened guarantees to know that it works. That is kind of the entire premise behind Rust. Make it extremely visible where the dragons may exist, because you have the key to unlock that door. Regarding memory safety, 70% of CVEs at Microsoft and in Chrome are memory safety bugs. I would say the choice of languages without memory safety is more based on legacy than some kind of insightful choice. https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-mor… https://security.googleblog.com/2022/03/whats-up-with-in-wild-exploits…

This comment is clearly bait, but I'm going to take it anyway and respond with a link to Microsoft's Security Response Center. This isn't exclusive to Linux at all (for better or worse) https://msrc-blog.microsoft.com/

The actual steps are described there: https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent… 1. Run up to date antivirus or EDR products that detect compromised SolarWinds libraries [...] 2. Block known C2 endpoints listed below in IOCs using your network infrastructure.[...] 3. Follow the best practices of your identity federation technology provider in securing your SAML token signing keys. [...] 4. Ensure that user accounts with administrative rights follow best practices, including use of privileged access workstations, JIT/JEA, and strong authentication. [...] 5. Ensure that service accounts and service principals with administrative rights use high entropy secrets, like certificates, stored securely.[...] 6. Reduce surface area by removing/disabling unused or unnecessary applications and service principals.[...]

Yeah totally agree for the experienced C/C++ developer, it is like unlearning all the things that make you good. Totally agree. Good developer is like building a series of great mental models. It is hard to start over. Like trying to do linked lists in Rust... But that being said, when you see that the majority of vulnerabilities are essentially memory lifetime issues (https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-p… you realize that we are all human. So something like Rust could help--especially new developers.

MSRC (Microsoft Security Response Center) — https://msrc.microsoft.com/ They’ll close a report as “no action” if the issue isn’t related to Microsoft products. That said, in my experience they’ve been a reasonable intermediary for a few incidents I’ve reported involving government websites, especially where Microsoft software was part of the stack in some way. For example, I’ve reported issues in multiple countries where national ID numbers are sequential. Private companies like insurers, pension funds, and banks use those IDs to look up records, but some of them didn’t verify that the JSON Web Token (JWT) used for the session actually belonged to the person whose national ID was being queried. In practice, that meant an attacker could enumerate IDs and access other citizens’ financial and personal data. Reporting something like that directly to a government agency can be intimidating, so I reported it to Microsoft instead, since these organizations often use Azure AD B2C for customer authentication. The vulnerability itself wasn’t in Microsoft’s products, but MSRC’s reactive engineers still took ownership of triage and helped route it to the right contacts in those agencies through their existing partnerships.

Probabilistic Arm MTE memory safety is a stepping stone to deterministic CHERI hardware, https://saaramar.github.io/memory_safety_blogpost_2022/ & https://news.ycombinator.com/item?id=39668053 The right kind of mitigations targets the 1st order primitive; the root cause of the bug. Hardware solutions: CHERI (Morello, CheriIoT), MTE Software mitigations: kalloc_type+dataPAC, AUTOSLAB, Firebloom, GuardedMemcpy, CastGuard, attack surface reduction Safe programming languages: Rust, Swift MTE/CHERI play pretty nicely - they help ensure that whatever bugs we have in these areas are killed at their root cause… MSR, MSRC and Azure Silicon pushed for… scaling CHERI down to RISC-V32E, the smallest core RISC-V specification. Microsoft Research open-sourced a hardware/software stack for CHERI in IoT devices, https://msrc.microsoft.com/blog/2023/02/first-steps-in-cheriot-securit… CHERI-based microcontroller that aims to… get very strong security guarantees if we are willing to co-design the instruction set architecture (ISA), the application binary interface (ABI), isolation model, and the core parts of the software stack… our microcontroller achieves the following security properties: Deterministic mitigation for spatial safety (using CHERI-ISA capabilities). Deterministic mitigation for heap and cross-compartment stack temporal safety (using a load barrier, zeroing, revocation, and a one-bit information flow control scheme). Fine-grained…

Speed is not the only thing why Rust makes sense: 1. Safe Rust disallows data races at compile time, see for example: https://msrc.microsoft.com/blog/2020/04/the-safety-boat-kubernetes-and… 2. WASM is getting more and more usage (also on the server side) and Rust is one of the best languages to compile to WASM at the moment 3. If you need to support multiple programming languages with one library it might make sense to write a Rust core and wrappers in other languages 4. Rust has explicit error handling, so it might make sense to write a Rust application in critical applications where you need to be sure you handled as much error conditions as possible 5. Sometimes an application doesn't necessarily need to be ultra fast, but needs to have predictable performance. In some situations Java or Go won't be much slower (or could be even faster) than Rust, but in Rust it might be easier to get lower latency variance. There is probably more, but I choose Rust for many projects that do not need Rust's speed and I believe this is also the case for many people writing Rust.

This depends what you mean by "security bulletins". In general, Microsoft did stop publishing from their traditional, hand written format a while back. The closest you get this is sort of thing now, which is completely automated and frequently wrong, and assumes you know what CVE you were searching for. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36434 One of the bigger vulnerabilities in recent times was Printnightmare, where they did write ups like this due to visibility. I don't feel it actually says much. https://msrc.microsoft.com/blog/2021/08/point-and-print-default-behavi… There were a lot of Twitter threads about the shitstorm that I can no longer find back when all their bulletins changed formats, but the general reason was moving their "good" bulletins behind an E5 license. Which again, I know some people consider "professional". So to actually answer your question, here's a screenshot from a paywalled security bulletin. You can see from the scrollbar I'm near the top, and the "Recommendations" are all Defender features (with "apply patch" almost a hidden detail). The statement about configuring AMSI is not a Sharepoint recommendation, it's a Windows security feature originally tied into Defender. https://ibb.co/WV1HN3q And everything from here on in this security bulletin on to Sharepoint vulnerabilities - of which very little useful technical information is presented - is about Defender. Of course, not just the EDR, the first…

Those who think C is inherently good can’t be convinced otherwise. Any argument will be dismissed with “programmers need do be better”. Any assertion will be dismissed as subjective, lacking data. Any data backed study from Microsoft [1] or Google [2], [3] will be dismissed as Big Tech hiring mediocre programmers. There will be vague references to “just use the right sanitizers”. Ultimately we need to recognise that for some people, language is a core part of their identity. At that point criticising “their” language hurts them. If we’re talking to someone who feels this way, it’s best to politely say “is that so?” and gently disengage. I know it’s tempting to think that we could show them just one compelling data point that will change their minds. But that’s not any more possible than convincing someone to stop believing in religion by pointing out factual inconsistencies in scripture. If you tell a committed Christian that Jesus couldn’t have been born in 0AD because Herod died in 4BC and the census they were travelling for happened in 7AD … is that going to make them reconsider everything about their religion? No, they’ll dismiss this as a minor issue that can be worked around. Same with $language programmers. 1 - https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-mor… 2 - https://www.chromium.org/Home/chromium-security/memory-safety/ 3 - https://security.googleblog.com/2022/12/memory-safe-languages-in-andro…

That doesn't excuse downplaying the security issues so common when using languages that do not offer memory safety. Microsoft: >we’ll peek at why we think that Rust represents the best alternative to C and C++ currently available. First, there are plenty of fantastic memory safe languages already available and widely used inside and outside of Microsoft, including .NET languages like C# or F# and other languages like Swift, Go, and Python. We encourage anyone who is currently using C or C++ to consider whether one of these languages would be appropriate to use instead. We, however, are talking about the need for a safe systems programming language (i.e., a language that can build systems other software runs on, like OS kernels). Such workloads need the speed and predictable performance that C, C++, and Rust provide. When thinking about why Rust is a good alternative, it’s good to think about what we can’t afford to give up by switching from C or C++ — namely performance and control. Rust, just like C and C++ has a minimal and optional “runtime”. Rust’s standard library depends on libc for platforms that support it just like C and C++, but the standard library is also optional so running on platforms without an operating system is also possible. Rust, just like C and C++, also gives the programmer fine-grained control on when and how much memory is allocated allowing the programmer to have a very good idea of exactly how the program will perform every time it is run.…

TL;DR: Some Windows configuration have bad permissions on their SAM database. If a standard user has access to shadow copies (VSS), this can lead to privilege escalation. Microsoft recommends to [1]: 1) Restrict access to the contents of %windir%\system32\config: - Command Prompt (Run as administrator): icacls %windir%\system32\config*.* /inheritance:e - Windows PowerShell (Run as administrator): icacls $env:windir\system32\config*.* /inheritance:e 2) Delete Volume Shadow Copy Service (VSS) shadow copies: - Delete any System Restore points and Shadow volumes that existed prior to restricting access to %windir%\system32\config. - Create a new System Restore point (if desired). -- Also, please note that some authorities seem to adress this subject carefully. The French national cybersecurity agency (ANSSI) has for instance published a News bulletin [2] but no "real" Security bulletin of this vulnerability [3]. In its News bulletin, the ANSSI specifies that it also affects Windows Vista RTM :). However, the ANSSI also says that deleting VSS entries (step 2 of Microsoft recommendations) "must be decided after evaluating the advantages and disadvantages with regard to the risks, in particular because there may be other possibilities for privilege escalation depending on the level of security of your information system." [1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934 [2] https://www.cert.ssi.gouv.fr/actualite/CERTFR-2021-ACT-031/ [3]…

The reuters link posted here is click-bait junk. This section from the Microsoft blog provides better context. >We detected unusual activity with a small number of internal accounts and upon review, we discovered one account had been used to view source code in a number of source code repositories. The account did not have permissions to modify any code or engineering systems and our investigation further confirmed no changes were made. These accounts were investigated and remediated. >At Microsoft, we have an inner source approach – the use of open source software development best practices and an open source-like culture – to making source code viewable within Microsoft. This means we do not rely on the secrecy of source code for the security of products, and our threat models assume that attackers have knowledge of source code. So viewing source code isn’t tied to elevation of risk. https://msrc-blog.microsoft.com/2020/12/31/microsoft-internal-soloriga…

Diane wrote an analysis of how many bugs would have been avoided had the Servo style system been in Gecko all along: https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rus… "There’s a significant overlap between memory vulnerabilities and severe security problems. Of the 34 critical/high bugs, 32 were memory-related." Rust doesn't fix everything, and this result won't hold for code that is itself security logic (ie, crypto implementation) as logic errors are also very bad. But fixing memory safety does address almost all the high and critical severity issues. Microsoft published similar research: https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-pro… Keep in mind that the Gecko style system has had two decades of work before the Rust code came along, and was written by some excellent programmers. It was extensively fuzzed for years. And still, Rust has enormous potential to solve these security issues. Only time will tell if the next decade with Rust will pan out as the data seem to predict, but I am quite hopeful.

That page eventually leads to the CVE page: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21204 While that's still pretty vague, it sounds like the issue was that something running as SYSTEM (the page seems to indicate some part of Windows Update) was not correctly checking if inetpub was a symlink or something along those lines. It also links to a script to set ACLs on that directory; presumably that's not possible to do if the directory doesn't exist. It would probably be better to fix whatever component to not have the link traversal bug, but maybe there's some reason that makes the proper fix infeasible…

> I think notepad.exe is the strongest example of this right now. It’s a strong bad example, i.e. an example of software with doesn’t know when to stop. https://blogs.windows.com/windows-insider/2026/01/21/notepad-and-paint… https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20841

Good point re: "RCE" though the CVSS score is 7.8/high severity; some more flavor per the FAQ at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20841 > According to the CVSS metric, the attack vector is local (AV:L). Why does the CVE title indicate that this is a remote code execution? > The word Remote in the title refers to the location of the attacker. This type of exploit is sometimes referred to as Arbitrary Code Execution (ACE). The attack itself is carried out locally. > For example, when the score indicates that the Attack Vector is Local and User Interaction is Required, this could describe an exploit in which an attacker, through social engineering, convinces a victim to download and open a specially crafted file from a website which leads to a local attack on their computer.

Windows 11 LTSC still has the old school notepad.exe (and calc.exe) instead of this UWP abomination. Also: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20841

The concern is that more features introduces more risk. See CVE-2026-20841 for a recent example. If the application remained a simple text editor, it is unlikely exploits like this would be possible. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20841

> An attacker could trick a user into clicking a malicious link inside a Markdown file opened in Notepad, causing the application to launch unverified protocols that load and execute remote files. From https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20841 (there are many collapsible elements on this page, and they're also just for term definitions, sigh) What a fucking terrible page for someone unfamiliar with the site. the "Learn More" links will allow you to learn what the terms "CWE", "CVSS", "Product Status" mean, but not to learn more about this vulnerability... Anyway, it's not related to CoPilot, but because Notepad makes links clickable now...

It is to do with link handling: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20841 > An attacker could trick a user into clicking a malicious link inside a Markdown file opened in Notepad, causing the application to launch unverified protocols that load and execute remote files.

Probably a better link: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55315

Note that this affects ".net core", not ".net framework" https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55315

"1.1 18 Sep 2025 The CVSS score for this vulnerability has been updated to reflect a change in the Attack Complexity metric from High to Low." https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55241