1307 points by Tomte 1911 days ago | 317 comments on HN
| Moderate positive
Contested
Editorial · v3.7· 2026-02-28 07:50:50 0
Summary Security & Privacy Advocates
This GitHub repository hosts a detailed security vulnerability disclosure documenting critical remote code execution flaws in Microsoft Teams that enable zero-interaction attacks threatening user security and privacy. The author advocates forcefully that these threats warrant maximum severity recognition, criticizes the vendor's inadequate response, and publicly exercises freedom of expression to expose a corporate accountability failure affecting millions of users.
> Microsoft accepted this chain of bugs as "Important" (severity), "Spoofing" (impact) in O365 cloud bug bounty program. That is one of the lowest in-scope ratings possible.
This is beyond believe: a RCE classified as "Spoofing".
This essentially allows you to infect all (online) machines running Teams in some timespan, because of the wormability, if I understand this correctly. There are 115 million daily active users.
The absurdly low rating by Microsoft is horrendous.
hmm...seems a bit counterproductive trying to build good will by offering a bounty program and promptly nuking said good will with questionable ratings decisions.
Immediate money saved, long term rep damage incurred.
These are some of the reasons why I refuse to use the desktop application and on Linux at least, it isn't hard to define a shortcut that works like one; path ~/.local/share/applications/ms-teams.desktop
[Desktop Entry]
Version=1.0
Name=Microsoft Teams
Comment=Teams without Electron
GenericName=Teams
Exec=/usr/bin/chromium-browser --user-data-dir=/home/prussian/.config/ms-teams --app=https://teams.microsoft.com/_#/conversations/General
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=ms-teams
Categories=Network;InstantMessaging;
Keywords=teams;messaging;internet;
X-Desktop-File-Install-Version=0.23
I'm confused about the scope of the RCE. Can it escape the Chromium renderer sandbox? Or is that sandbox disabled? Based on the following:
> MS Teams ElectronJS security: remote-require is disabled & filtered, nodeIntegration is false, webview creation is filtered and normally removes insecure params/options. You cannot simply import child_process and execute arbitrary code or create a webview with a custom preload option.
it looks like they did everything right.
I would like this thread to go beyond outrage at how Microsoft handled this, or another excuse to bash Electron. What lessons can developers using Electron take from this? (No, "don't use Electron" doesn't count.)
Unbelievably lax response. However, I've encountered a similar response with Microsoft 365 login phishing sites being hosted with a nice windows.net SSL certificate. Sites remained up for more than a week after reporting through official channels (CERT). Never received a response.
I refuse to install this junk, it's Google Meet or bust for us and so far that has served us well. Zoom, MS and lots of others besides have all had their share of vulnerabilities to the point that I'm not happy discussing anything under NDA on one of those channels. For now Google seems to have their act together on this.
Reported information leaking from password fields back in Windows 8 days.
I was even busier back then than now and found no application besides getting information about an already filled in password, but I was still massively underwhelmed by the response which basically boiled down to "that's funny, thanks, bye".
Last year I found a really ugly glitch were you can easily get files unencrypted past an older (but still available) version of Azure Information Protection tooling.
Whats the reason to even participate in most bug bounties for serious shit like this knowing you could get 10-100x more submitting to Zerodium? Is it the hope of getting on some 'hall of fame' which might land a job offer?
Like, If I found a exploit for something random like skype/slack/etc.. that let you run code on any targets machine with zero interaction, there is zero chance my first stop would be the bug bounty program. For serious exploits, I believe you can get up to 2 million bucks with zerodium. Just seems like a no brainer.
Now that said, I would definitely use the bug bounty program for boring/low impact stuff like XSS and whatnot that has limited value/impact as nobody else would likely ever buy it for that much higher of a price.
This reminds me of finding and trying to report a bug in Internet Explorer 5.5 20+ years ago (not a difficult task). To report a bug, I had to pay. Yes that's right, I had to put in a credit card, and pay $100.
If it turned out it was deemed to be a real bug, I would be refunded my $100 money. If it wasn't, well that should teach me for wasting their time.
Guess the folks running the bug program got promoted.
Microsoft Teams is clearly a product worrying about user base growth and nothing else. There are bugs, quirks and performance issues everywhere, and then - out of nowhere - you get an update about its new "AI Real-time Speech Translation for Your Calls!".
They are just pushing new features in and hoping that everything will hold together until they dominate the market. I'm not saying that this is wrong, just that this is a fact for anyone that uses Teams on a daily basis.
IMO the best situation _for customers_ would be for researchers to sell their discoveries in an open market, one in which MS is free to pay "market price" (they certainly have the funds).
In the short-term, MS buying these discoveries would allow them to close vulnerabilities, ensure researchers are compensated appropriately, and establish a clear financial cost to poor security. The long-term effects would be increased security research, shorter windows of vulnerability, and more secure software.
Fun. What is interesting to me is that my work computer just got unannounced update that included MS Teams pop up. I get that my IT team dropped the ball by just allowing this to show willy nilly, but I don't think we can take MS off the hook for installing, promoting their own solution in user's face ( along with telling me snip tool is moving away, resetting all file associations, and making pdf default to IE.. ).
Greyhats with good anonymization need to start forcing companies to take their bounty programs seriously instead of the joke that it is now. We are too nice.
This is a bug that should have a minimum payment of $1 million.
The reason is probably to safe money. The bug bounty for a critical RCE would be between 10k$ and 20k$ depending on the quality of the report.
Important Spoofing is rated for 3k$ and 500$.
So that is basically a giant middle finger to the security researchers.
The RCE isn't classed as "Spoofing". The RCE is in a product for which Microsoft don't have any bug bounty product at all (they only run a bug bounty for a very limited number of products, and Microsoft Teams Desktop is not one of them). Hence the RCE falls outside of the classification.
The technicality is still absurd and beyond belief, but I'd say the responsibility for that absurdity falls with company policy, not with the MS security staffer's classification.
Is there any tell-tale sign this happened to you? I had a really weird experience on Mac last week: I opened up my machine and when I focused on teams I got a security alert saying something called Endgame from Elastico was demanding permissions. Never downloaded it but there it was in Applications.
Yeah, although technically it's "out of scope", I think there are times when you should stop debating the technicalities and consider the business impact.
I mean, do you look at that demo and think "yeah, that's technically just 'important' let's fix it in 2 months"?
I do similar things, but a few weeks ago I had to learn, that many of the issues I had with the online Spotify Player (slow loading times, incomplete pages, not playing music) were caused by the included ServiceWorker. Gladly I could disable it in my Firefox Profile and now everything works just fine.
Maybe the local version wouldn't have had that problem.
The article explains the technical details of the render process escape. Contrary to all the current replies to this comment, it does not look to me that this is using a generalized Electron escape; rather, it is using specific main/render IPC calls which Teams has implemented unsafely as the escape mechanism. Perhaps folks are confusing this with an electron sandbox issue because Teams happens to have called the variable containing their IPC APIs "electronSafeIpc".
Maybe some people are ethically against selling to an organization that then resells the zero day to governments instead of, you know, fixing the problem.
Which is pretty despicable for a chat application.
I blame the constant bloat of unwanted features. Each comes with it's own inherent risk of vulnerability, yet it seems like these companies can help themselves but to add "integrations" that nobody wants or asks for from a chat application.
I wonder if the team giving these ratings is the same team responsible for introducing the bug in the first place? I could see why someone in that situation would be incentivized to downplay the severity of a bug report like this.
I had the same reaction to this when I was told by Microsoft, however this description seems intentionally misleading. Microsoft Support accepts calls for support and bug reports. There's a fee for the support. If it turns out that the issue is a defect, then you won't pay for the support call.
Unfortunately, this was the only way to report a bug at the time.
I just today switched to Google Chat from Teams and find it severely lacking. I don’t see a way to call or screenshare with another person/group unless I generate a Meet url and paste it in the chat? Is it meant to be that way or our admin has not enabled something?
Could you clarify the "one of five" statement please? Are the other 4 vulnerabilities still unfixed, or they are fixed but a write-up is still pending?
If there are still 4 unfixed RCE bugs in Teams I'd rather people uninstall Teams than wait for the fix...
When they introduced IE7, they broke ClickOnce launchers all around the globe due to the new download prompting. I raised a defect with my MS Partner support dude and normal MS support. All they managed was a registry fix shipped out to turn an old flag on that was removed from the UI but was still in the code inside IE. I did the diagnostic work to get that far.
After arguing for months with various support people at Microsoft I managed to get hold of people on both the IE and CLR teams and they both pointed at each other and refused to fix anything blaming the other team.
They called me every 6 months to ask me to close the ticket and I denied it because it wasn't fucking fixed. Eventually they stopped calling when Microsoft Connect was shut down. I wonder how many millions of issues they solved at that time!
Oh no wait, the issue still exists in IE11. They fixed it in old Edge.
This was a manual registry fix we had to deploy to 20,000 users at over 500 companies for 10 years.
Eventually we rewrote the software so it didn't use ClickOnce, instead passing context to the application via a shell protocol handler (much like Slack does).
Incidentally we're no longer an MS Gold partner and have no certified staff any more. This is not a coincidence. They did a shitty job and like hell we were paying any further. Amazon got our business in the end.
The issue?
You can't set window.location.href=""; to a clickonce activation link because of a race condition in the download bar in IE.
They could ummm.... build a cross-platform UI framework that rivals Electron without the security and memory bloat issues? I think that's the plan with MAUI.
Content directly advocates that the vulnerability represents a critical threat to the security of person; explicitly details how code execution undermines personal security and bodily autonomy (microphone/camera access); criticizes vendor's failure to recognize this severity
FW Ratio: 57%
Observable Facts
The writeup states 'arbitrary command execution on victim devices with no interaction from victim, cross platform'
Author lists 'Keylogging, access to microphone, camera etc.' as demonstrated impacts
Content explicitly critiques Microsoft's severity rating as inadequate for a remote code execution vulnerability
The author provides technical proof-of-concept to demonstrate the threat is real
Inferences
The emphasis on 'no interaction required' and cross-platform execution indicates the author considers this a severe, systemic threat to fundamental security
The detailed itemization of surveillance capabilities (microphone, camera, keylogging) suggests advocacy that personal bodily autonomy is at stake
The criticism of Microsoft's rating implies that security of person should take precedence in vendor vulnerability assessment
Content strongly advocates for privacy protection by detailing how the vulnerability enables comprehensive invasion of privacy: access to 'private conversations, messages, files, call logs,' O365 documents, mail, notes, SSO tokens; frames privacy as fundamental right that was violated
FW Ratio: 60%
Observable Facts
Writeup lists 'Access to private conversations, messages, files, call logs and everything else you have in MS Teams' as vulnerability impact
Author describes 'SSO token stealing for all org users' enabling 'account takeover - which means access to company mail, documents, notes, everything in O365'
Content emphasizes 'Complete loss of confidentiality & integrity for end users - access to private chats, files, internal network, private keys and personal data outside MS Teams'
Inferences
The detailed cataloging of privacy invasions (messages, files, tokens, microphone, camera) indicates author considers privacy a fundamental, non-negotiable right
The critical framing of Microsoft's response suggests advocacy that privacy threats require maximum-severity response from vendors
Content is itself a prominent exercise in freedom of expression: detailed critical analysis of a major technology company's security response, published without censorship; author advocates for the right to publicly disclose vulnerabilities affecting millions
FW Ratio: 50%
Observable Facts
The writeup is publicly available without paywalls or login requirements on GitHub
Author directly criticizes Microsoft's decisions and ratings with strong language ('Thanks Microsoft! 😂', 'A new joke is born')
Content includes detailed technical analysis and code snippets enabling others to understand the vulnerability
Inferences
The publication itself demonstrates exercise of freedom of expression to critique major corporation
GitHub's hosting demonstrates structural support for this form of critical speech about corporate conduct
The author's choice to publicly disclose (after responsible disclosure period) reflects advocacy for the right to speak about security threats affecting society
Content frames security threats as fundamental violations of human dignity and the rule of law; advocates that inadequate response to critical vulnerabilities contradicts justice principles
FW Ratio: 50%
Observable Facts
The writeup opens with statements linking security to Microsoft's responsibility and user trust
The author emphasizes the systemic nature of the threat ('Everyone gets exploited') and its cascade across organizations
Inferences
The author treats the vulnerability as a violation of fundamental human dignity, not merely a technical issue
GitHub's role in hosting critical disclosure publicly aligns with Preamble principles of transparency and accountability
Content advocates for proper security standards and international norms around responsible disclosure; critiques deviation from expected industry standards; supports accountable global governance of technology
FW Ratio: 67%
Observable Facts
Author advocates for consistent, serious treatment of RCE vulnerabilities across all platforms
The detailed argumentation about impact is framed as supporting international security norms
Inferences
The insistence on proper severity ratings reflects advocacy for adherence to international security standards and norms
Author demonstrates sense of responsibility to disclose security vulnerabilities responsibly; maintains ethical approach (redacted payloads, vendor notification before public disclosure), advocating for responsible community conduct in security research
FW Ratio: 67%
Observable Facts
Author states 'redacted no new window RCE payload until ~2021 as requested by Microsoft,' showing respect for responsible disclosure timeline
The writeup follows coordinated disclosure pattern: internal reporting, months of engagement, then public disclosure after fixes deployed
Inferences
The author's adherence to responsible disclosure norms suggests advocacy for community duties to limit harm while enabling accountability
Content notes the vulnerability affects all Microsoft Teams users uniformly ('Impacts all messaging thread types'), implicitly advocating for equal protection of all persons
FW Ratio: 67%
Observable Facts
Author explicitly states vulnerability impacts 'all messaging thread types - private, threads, groups etc.'
Writeup describes universal exposure of all Teams users without differentiation
Inferences
The emphasis on universal vulnerability suggests advocacy that all users deserve equal security protections
Content critiques unequal treatment by Microsoft: cloud version rated 'Important, Spoofing' while desktop version rated 'Critical, Remote Code Execution'; advocates for equal protection and consistent legal treatment
FW Ratio: 67%
Observable Facts
Author states Microsoft rated vulnerability differently for cloud ('Important, Spoofing') versus desktop ('Critical, Remote Code Execution')
Writeup questions the rationale for this differential treatment
Inferences
The critique of unequal severity ratings suggests advocacy for equal protection under vendors' own security standards
Content documents the author's engagement with Microsoft's vulnerability disclosure process and complaint mechanisms; shows attempt to seek remedy for inadequate response, though process was ultimately unsuccessful
FW Ratio: 67%
Observable Facts
Author describes multi-month interaction with MSRC: 'Reported critical remote code execution bugs in Microsoft Teams, August 31st, 2020' through November 2020
Writeup documents that author 'sent a list of bulletpoints...in argumentation to MSRC employees' seeking reconsideration
Inferences
The detailed documentation of remedy-seeking process, while unsuccessful, demonstrates advocacy for effective grievance mechanisms
Content discusses potential for unwanted surveillance (access to microphone, camera, keystroke logging) which relates to protection from degrading treatment; mild advocacy for such protections
FW Ratio: 67%
Observable Facts
Writeup lists 'Keylogging, access to microphone, camera etc.' as exploitable capabilities
Author frames these as components of 'Complete loss of confidentiality & integrity for end users'
Inferences
The discussion of surveillance capabilities implies concern about protection from degrading or dehumanizing treatment through forced surveillance
Content mentions vulnerability enables access to 'company internal documents, O365 documents' and 'private data...outside MS Teams,' implying threat to property rights in personal and corporate information
FW Ratio: 67%
Observable Facts
Writeup includes 'Access to...private keys and personal data outside MS Teams' among vulnerability impacts
Author describes O365 document/mail access as consequence
Inferences
The listing of document and file access suggests author views proprietary/personal information as property requiring protection
Content discusses vulnerability affecting workplace security for millions of Microsoft Teams users; mild implication that work environment security is a right
FW Ratio: 67%
Observable Facts
Author notes Microsoft Teams has '115 million daily active users,' many in workplace contexts
Vulnerability impacts corporate networks and company devices
Inferences
The emphasis on workplace user numbers suggests concern for security in work environments
GitHub's structure explicitly enables freedom of expression by hosting controversial, critical security research; public accessibility demonstrates platform's commitment to enabling speech about corporate accountability
GitHub's public hosting of this security disclosure structurally enables awareness and protective action; transparency about threats to security of person aligns with this right
Content notes the vulnerability affects all Microsoft Teams users uniformly ('Impacts all messaging thread types'), implicitly advocating for equal protection of all persons
Content discusses potential for unwanted surveillance (access to microphone, camera, keystroke logging) which relates to protection from degrading treatment; mild advocacy for such protections
Content critiques unequal treatment by Microsoft: cloud version rated 'Important, Spoofing' while desktop version rated 'Critical, Remote Code Execution'; advocates for equal protection and consistent legal treatment
Content documents the author's engagement with Microsoft's vulnerability disclosure process and complaint mechanisms; shows attempt to seek remedy for inadequate response, though process was ultimately unsuccessful
Content mentions vulnerability enables access to 'company internal documents, O365 documents' and 'private data...outside MS Teams,' implying threat to property rights in personal and corporate information
Content discusses vulnerability affecting workplace security for millions of Microsoft Teams users; mild implication that work environment security is a right
Content advocates for proper security standards and international norms around responsible disclosure; critiques deviation from expected industry standards; supports accountable global governance of technology
Author demonstrates sense of responsibility to disclose security vulnerabilities responsibly; maintains ethical approach (redacted payloads, vendor notification before public disclosure), advocating for responsible community conduct in security research