{ "id": "d5f61154-994a-4a0a-9c47-9a8fb8c22dc4", "created_at": "2026-04-06T00:07:00.228098Z", "updated_at": "2026-04-10T03:23:51.65547Z", "deleted_at": null, "sha1_hash": "e909f174fcc4360c9084ea2e50bdd2c4c519d0a5", "title": "GitHub Abuse Flaw Shows Why We Can’t Shrug Off Abuse Vulnerabilities in Security", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 702829, "plain_text": "GitHub Abuse Flaw Shows Why We Can’t Shrug Off Abuse\r\nVulnerabilities in Security\r\nBy Dvir Sasson — Director of Security Research at Reco AI May 13, 2024\r\nPublished: 2024-05-13 · Archived: 2026-04-05 21:51:48 UTC\r\nSecurity has always been a game of risk management, not risk elimination. Every decision to address one threat means\r\npotentially leaving another unattended. That deciding of which threat to address – and in what order – is the name of the\r\ngame. In this triage process, abuse vulnerabilities, i.e., exploiting legitimate features of a platform in unintended ways to\r\nconduct digital misdeeds such as phishing campaigns, can get pushed down the priority list of security issues. I would like to\r\nargue that it's time we stop separating the concept of abuse vulnerabilities and security vulnerabilities.\r\nUnlike security vulnerabilities that are, in essence, exploited loopholes or bugs in the code, fixes for abuse vulnerabilities\r\ncan be slow to come. Yet these openings for abuse can easily lead to disaster if left unattended. Recent figures show that\r\n68% of breaches originate from these exact types of exploitations involving the human element making a mistake such as\r\nphishing attempts or abuse vulnerabilities.\r\nAs an example, let's examine a recent abuse vulnerability I found in GitHub. This vulnerability bypasses traditional email\r\nsecurity controls and takes advantage of GitHub's lack of content sanitization, which enables the distribution of malicious\r\ncontent on its platform.\r\nRefresher: What is GitHub?#\r\nGitHub is a widely popular code hosting platform owned by Microsoft. It allows developers to collaborate, share code, and\r\nmanage projects effectively. With its widespread adoption and integration into modern development workflows, GitHub has\r\nbecome a crucial tool for many organizations, especially in software development and production. In turn, this widespread\r\nadoption has led to threat actors increasingly targeting it in order to gain access to proprietary code, keys/access to systems,\r\nand more.\r\nA Summary of GitHub's Abuse Vulnerability#\r\nWhile GitHub offers powerful collaboration features, we discovered a way to abuse its functionality and bypass security\r\nconfigurations to target organizational users with spear-phishing emails. Here are some of the highlights of this issue.\r\n1. Mention Mechanism: When attempting to mention a user with an \"@\" sign, GitHub suggests usernames. However,\r\nif you know a specific user's username (even within an organization), mentioning them will notify them via their\r\nconfigured notification method, which is typically email by default. This gives threat actors the ability to use\r\nGitHub's notification as a way to email and contact users in an organization that will not be caught by email security\r\nmechanisms.\r\n2. Lack of Privacy Controls: GitHub does not allow users to set granular privacy controls for who can mention or tag\r\nthem. This lack of control means that anyone can potentially mention a user, even if they are not part of the same\r\norganization or project.\r\n3. Global Notification Settings: GitHub only allows users to set their notification preferences globally, without fine-grained policies or whitelisting mechanisms.\r\n4. Abuse Persistence: While GitHub allows users to block and report threat actors and their issues, the attacker can\r\nsimply create a new user account, repository, and issue to restart the attack. This is made infinitely easier with AI and\r\nhttps://thehackernews.com/expert-insights/2024/05/github-abuse-flaw-shows-why-we-cant.html\r\nPage 1 of 4\n\nother bots that make this process trivial for threat actors.\r\n5. No Content Validation: GitHub does not perform any syntax validation or leverage language models to review\r\ncontent, potentially allowing malicious payloads to slip through.\r\nThe Attack Kill Chain#\r\nHere's a step-by-step breakdown of how threat actors can exploit this vulnerability:\r\n1. Set up Repository and Issue: The attacker creates a new repository or piggybacks on an existing one, then creates a new\r\nissue within it.\r\nThreat actors spin up a new repository, or even leeching on existing ones, creating new issues.\r\nWithin the issue, threat actors are able to create a Markdown based formatting. We even used an LLM to generate the\r\nfollowing text as an example of a threat actor creating an official-looking lure asking the user to sign into their account and\r\nchange their password.\r\nBy replacing the username with the correct victim's username, we can make sure that the email will be delivered safely,\r\nbypassing email security measures, because these email security mechanisms will assume that an email \"from\" GitHub\r\nalerting of a notification, similar to other such notifications necessary for the developer to perform their jobs.\r\nhttps://thehackernews.com/expert-insights/2024/05/github-abuse-flaw-shows-why-we-cant.html\r\nPage 2 of 4\n\nOnce submitted, the victim will receive the phishing email lure.\r\nAs you can see, the display name of the sender is derived from the abusing user's display name. The threat actor could easily\r\neven change this to something such as \"GitHub Security\" by changing the display name and not the user name.\r\nThe malicious sender is notifications@github.com, which means it's a reputable sender that's being abused to deliver\r\nmalicious content.\r\nImplications of this abuse vulnerability in GitHub#\r\nhttps://thehackernews.com/expert-insights/2024/05/github-abuse-flaw-shows-why-we-cant.html\r\nPage 3 of 4\n\nThis vulnerability poses a significant risk since it allows threat actors to bypass email security controls and deliver malicious\r\ncontent directly to targeted individuals within organizations. You'll notice that no malicious code was ever deployed. Instead,\r\nall of this was accomplished using GitHub's own product in ways it was not intended. The convincing nature of the emails,\r\ncoupled with the abuse of GitHub's trusted domain, increases the likelihood of successful phishing attacks on busy\r\ndevelopers.\r\nResponsible Disclosure and GitHub's Response#\r\nWe responsibly disclosed this abuse vulnerability to GitHub through their bug bounty program on HackerOne. Their\r\nresponse:\r\nGitHub's official response (from HackerOne):\r\nHi @dviros,\r\nThanks for contacting us. We are aware of the behavior you are describing and consider it to be an abuse issue and\r\nnot a security vulnerability. We take abuse and spam seriously and have a dedicated team that tracks down\r\nspammy users.\r\nBest regards and happy hacking!\r\n@securabee\r\nGitHub's response indicated that they consider this behavior an abuse issue rather than a security vulnerability, despite these\r\ntypes of abuses account for the vast majority of breaches. They acknowledged the potential for spam and abuse and stated\r\nthat they have a dedicated team to track down and address such issues.\r\nWhile GitHub's response is appreciated, we believe that more proactive measures should be taken to mitigate this\r\nvulnerability effectively. Some recommendations include:\r\n1. Enable Privacy Controls: Allow users, especially enterprise users, to set granular privacy controls and whitelist\r\nindividuals or organizations that can mention or tag them.\r\n2. Implement Content Validation: Leverage language models or other techniques to validate the content of issues,\r\ncomments, and mentions, particularly when users attempt to mention others for the first time or when the repository\r\nhas not been previously interacted with by the victim.\r\n3. Monitor Outgoing Emails: Implement mechanisms to monitor outgoing emails from notifications@github.com and\r\nblock any malicious content being delivered.\r\n4. Streamline Untagging Process: Provide users with a quick and easy way to \"untag\" themselves from being\r\nmentioned in issues, pull requests, or comments, rather than relying solely on the \"unsubscribe\" option.\r\nConclusion#\r\nWhile GitHub is a powerful and widely adopted platform, this vulnerability highlights the importance of abuse\r\nvulnerabilities as the first step taken by threat actors to perpetrate breaches. Simply automatically classifying abuse\r\nvulnerabilities as separate from security vulnerabilities discounts their importance in attacks by threat actors.\r\nDvir Sasson — Director of Security Research at Reco AI\r\nhttps://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIsDXLDxfzD9NNyhetG4qGm4HaH5fMaUR37JZKxYOBeVjJl6TZwD9tesXBL_GQkx\r\nBPpSMqwxMYWfsYOWvamq2FoZWVleZYzVcObrq5rQDPP2UJP9wo-XjkXipd_Ad9/s100-rw-e365/reco.png\r\nFound this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter and\r\nLinkedIn to read more exclusive content we post.\r\nSource: https://thehackernews.com/expert-insights/2024/05/github-abuse-flaw-shows-why-we-cant.html\r\nhttps://thehackernews.com/expert-insights/2024/05/github-abuse-flaw-shows-why-we-cant.html\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://thehackernews.com/expert-insights/2024/05/github-abuse-flaw-shows-why-we-cant.html" ], "report_names": [ "github-abuse-flaw-shows-why-we-cant.html" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434020, "ts_updated_at": 1775791431, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/e909f174fcc4360c9084ea2e50bdd2c4c519d0a5.pdf", "text": "https://archive.orkl.eu/e909f174fcc4360c9084ea2e50bdd2c4c519d0a5.txt", "img": "https://archive.orkl.eu/e909f174fcc4360c9084ea2e50bdd2c4c519d0a5.jpg" } }