Top 10 web application incidents in 2026

A compromised Context.ai Google Workspace OAuth app let an attacker pivot from a Vercel employee's account into Vercel's internal systems in April 2026, where the attacker listed and decrypted customer environment variables not marked as sensitive, according to Vercel's security bulletin. Hudson Rock researchers traced the initial access to Lumma Stealer malware on a Context.ai employee's computer in February 2026, and Vercel confirmed exposure for a limited subset of customers plus a small number of additional compromised accounts while reporting no exposure of variables marked sensitive and no tampering with its npm packages. The incident anchors a top-10 list of confirmed 2026 web application attacks in which four began with code flaws, four with logic vulnerabilities, misconfigurations or stolen tokens, and two victims have not disclosed how the attacker got in.

In April 2026, a support ticket gave an attacker a way into the admin side of a learning platform used by thousands of schools and universities. In September, a vulnerability in an image upload server handed another attacker 23.62 million user records. Between those two cases came an AI recovery assistant that sent password reset links to the wrong people, customer portals that answered anonymous queries with private CRM data, and a GitHub token from 2022 that could still open a path to production. Each incident on this list is a confirmed attack on a web application or the services behind it, carried out in 2026. The causes split into three groups: 1. Four began with a code flaw , such as remote code execution or stored XSS. 2. Four began with a logic vulnerability, a misconfiguration, or a stolen token . The request the attacker sent looked legitimate to the application. 3. Two victims have not disclosed how the attacker got in . The first group calls for fast patches and careful code review. The second group calls for tests that check what each user, role, and integration can reach, because the malicious traffic often looks like normal use. By the end of this read, you will know the top 10 web app incidents in 2026, what happened in each, what the evidence confirms, and what each one teaches. The 2026 top 10 web app incidents in brief How we chose the ten Every incident on this list meets four conditions: 1. Confirmed malicious activity. The victim, a regulator filing, or published forensic research confirms the attack. A hacker’s claim alone did not qualify. 2. A web application at the center. The attacker went after a web application or the services and integrations behind it. 3. A 2026 attack. The incident took place in 2026. 4. A real-life consequence. The attack led to data theft, account takeover, or service disruption, as opposed to being a theoretical demonstration of a possible attack path. We list the incidents in the order the attacks began, as far as public evidence dates them. The numbering is not a ranking, which makes this list different from a list of the top 10 web app breaches ordered by size. Where a victim or record count comes from attackers, such as the 275 million figure in the Canvas ransom note, we state that explicitly. Keep in mind that some investigations remain open, so details may change. 1. Vercel: Trust inherited through an OAuth grant A compromised AI tool gave an attacker a path from one employee’s account into Vercel’s internal systems. What happened Vercel’s security bulletin http://vercel.com/kb/bulletin/vercel-april-2026-security-incident traces the incident to Context.ai, an AI tool that a Vercel employee used. Context.ai’s Google Workspace OAuth app formed part of a wider compromise. From there, the attacker: 1. Took over the employee’s Google Workspace account. 2. Used it to enter the employee’s Vercel account. 3. Moved into a Vercel environment. 4. Listed and decrypted environment variables that customers had not marked as sensitive. According to researchers at Hudson Rock https://www.infostealers.com/article/breaking-vercel-breach-linked-to-infostealer-infection-at-context-ai/ , the first step was credential theft: Lumma Stealer malware on the computer of a Context.ai employee in February 2026. Vercel described the attacker as highly sophisticated, with a detailed grasp of its product API surface https://equixly.com/blog/2024/04/24/api-attack-surface/ . What the evidence confirms - Vercel confirmed exposure for a limited subset of customers and later found a small number of additional compromised accounts. - Vercel has not reported any exposure of variables that customers had marked as sensitive. - Vercel and its partners confirmed that nobody tampered with the npm packages Vercel publishes. - A forum seller who used the ShinyHunters name offered alleged Vercel data for USD 2 million on BreachForums https://www.securityweek.com/next-js-creator-vercel-hacked/ . ShinyHunters reportedly denied involvement, and no one has verified the seller’s claims. The lesson for security teams Each OAuth consent extends your trust to another company’s security. Review which apps can access corporate accounts, remove the ones nobody uses, and store secrets as sensitive by default. These steps limit how much a single account takeover can expose. 2. Salesforce Experience Cloud: Guest profiles with too much reach Attackers pulled CRM data from Experience Cloud portals whose guest settings let anonymous visitors see too much. What happened Salesforce Experience Cloud lets companies publish portals that visitors can browse without an account. A shared guest profile decides what those visitors may see. Attackers took AuraInspector, an open-source audit tool that Mandiant released for defenders, and changed it to pull data instead of only flagging exposed objects. The modified tool probes the /s/sfsites/aura endpoint of each portal. It lets unauthenticated attackers query CRM records directly where the guest profile grants broad object permissions. What the evidence confirms - Salesforce confirmed the activity https://www.salesforce.com/blog/protecting-your-data-essential-actions-to-secure-experience-cloud-guest-user-access/ and published guidance for customers. - Salesforce states that the attacks did not exploit a vulnerability in its platform. The weak point lies in guest settings that each customer manages. - Salesforce has not published the number of customers or records the campaign reached. - ShinyHunters claims https://www.helpnetsecurity.com/2026/03/11/shinyhunters-salesforce-aura-data-breach/ it has used this method since September 2025. That date rests on the attacker’s word alone. The lesson for security teams This security misconfiguration stems from overly permissive guest access: the platform enforced the permissions it had, but customers had granted anonymous visitors more access than their portals needed. Data that never appears on a public page stays reachable through the API behind it. Test each portal as an anonymous visitor, set external sharing defaults to private, turn off guest API access where the portal does not need it, and watch logs for bulk queries from guest sessions. Our article on the API authorization matrix https://equixly.com/blog/2025/10/07/authorization-matrix/ explains how to test these role boundaries. 3. Instagram: An AI support agent that skipped the ownership check A missing check in Meta’s AI support tool let attackers reset passwords on accounts they did not own. What happened Meta’s High Touch Support tool used AI to help people who had lost access to their Instagram accounts. According to Meta’s breach notice https://www.all-about-security.de/wp-content/uploads/2026/06/Meta AI Support Tool Incident - AG Notification ME.pdf , a bug in a separate code path meant the tool did not verify that the email address a requester supplied matched the one on the account. Attackers asked the assistant to send a reset link to an address they controlled. They then logged in to any target account that lacked 2FA. KrebsOnSecurity reported https://krebsonsecurity.com/2026/06/hackers-used-metas-ai-support-bot-to-seize-instagram-accounts/ the defacement of prominent accounts, among them the Obama White House account and that of the Chief Master Sergeant of the U.S. Space Force. What the evidence confirms - Meta’s filing with the Maine Attorney General lists 20,225 people potentially affected, a breach date of April 17, and discovery on May 31. - Meta treats 20,225 as an upper bound, since some recovery requests may have come from the real owners. - Meta disabled the tool, invalidated the reset links it had sent, and committed to fix the email check before a relaunch. The lesson for security teams Account recovery is a login path, so it needs the same rigor as the login page. When an AI agent https://equixly.com/blog/2025/09/28/ai-agents-vs-agentic-ai/ can trigger a password reset, the application must enforce the ownership check in code, outside the model, and tests must cover that flow like any other route to an account. 4. Instructure Canvas: A support ticket that opened an admin session Two stored XSS flaws turned Canvas’s own support and discussion features into a path to elevated access. What happened On April 22, a user on the Free-for-Teacher tier of Canvas filed a support ticket with what Instructure described as a linked file with hidden code: a stored XSS payload. Three days later, a support representative opened the ticket, and the script ran inside that privileged session. The attacker stole an authorization token, gained elevated access, and pulled data through Canvas APIs https://scotthelme.co.uk/the-instructure-canvas-breach-2026-how-xss-in-a-support-ticket-compromised-275-million-students/ . Instructure spotted the unauthorized access on April 29 and cut it off. On May 7, the attacker returned. This time, a second XSS flaw in the Canvas discussion feature and an OAuth flow gave the attacker a new token https://www.instructure.com/incident update . The attacker then used the custom themes feature to place a ransom note on the login pages of roughly 300 institutions The Register https://www.theregister.com/security/2026/05/12/double-canvas-intrusion-confirmed-as-shinyhunters-resets-leak-deadline/5238361 counted about 330 . Instructure took Canvas offline in the middle of final exams. What the evidence confirms - Instructure confirmed the theft of names, email addresses, student ID numbers, course and enrollment data, and messages. - It reached an agreement with the attacker and has not disclosed the terms. - It has not published a victim count. TechCrunch https://techcrunch.com/2026/09/15/the-worst-hacks-and-breaches-of-2026-so-far/ puts the number above 30 million students and staff. The figure of 275 million comes from the ransom note. The lesson for security teams A help desk displays content that strangers write inside sessions that staff control. That combination puts support tools on the attack surface. Limit what a support session can do in customer tenants, sanitize uploaded files and rich text, and apply a strict Content Security Policy to internal tools as well as public pages. 5. World Food Programme WFP : An aid registration portal breach An intrusion into WFP’s aid registration app exposed personal data of Gaza households that depend on food assistance. What happened People in Gaza use the WFP registration application known as People Portal to sign up for food and cash assistance. WFP’s Situation Report 90 https://www.un.org/unispal/document/wfp-palestine-emergency-response-external-situation-report-90-reporting-period-1-31-may-2026/ confirms a cyberattack on the application on May 14. WFP shut the platform down, contained the intrusion, and continued aid to people already registered. It reports no impact on other WFP systems. WFP informed https://therecord.media/un-food-agency-investigates-gaza-aid-breach recipients through Telegram on May 31. It restarted the application https://www.thenewhumanitarian.org/news/2026/07/29/wfp-restarts-gaza-aid-registration-app-cyber-attack-questions-linger in late July with a PIN, an SMS code, and an extra security check. What the evidence confirms - The exposed data includes names, ID numbers, phone numbers, and location details such as neighborhood. - WFP has not published a count. The figure of about 600,000 households comes from a WFP spokesperson’s statement https://www.bleepingcomputer.com/news/security/un-world-food-programme-breach-affects-600-000-gaza-households/ . - More than 2 million people had submitted information to the application. - No one has claimed the attack, and WFP has not explained how it happened. The lesson for security teams When an application serves people in a conflict zone, a data leak can create physical safety risks, a concern that digital rights groups raised in this case. Threat models for such applications should assume capable, motivated adversaries. The application should also collect only what aid delivery requires. 6. Oracle PeopleSoft: A WAF rule is not a patch A zero day in Oracle PeopleSoft hit higher education hardest, and a second wave slipped past the WAF rules meant to stop it. What happened ShinyHunters, which Google tracks as UNC6240, attacked a security vulnerability in the Environment Management Hub of Oracle PeopleSoft. The flaw, CVE-2026-35273, allows remote code execution with no login and carries a CVSS score of 9.8. Mandiant and Google Threat Intelligence Group observed the attacks https://cloud.google.com/blog/topics/threat-intelligence/shinyhunters-targets-education-sector-oracle-exploit between May 27 and June 9. Oracle published its advisory on June 10, so the flaw served as a zero day. Inside victim networks, the attackers mapped PeopleSoft and WebLogic settings and tried hardcoded username and password lists over SSH against internal hosts. They dropped defacement notes and packed stolen data for the ShinyHunters leak site. Some organizations then blocked the vulnerable /PSEMHUB/ path with WAF rules but left the vulnerability unpatched. In September, the attackers came back https://cloud.google.com/blog/topics/threat-intelligence/shinyhunters-renewed-mass-exploitation-campaign-targeting-oracle-peoplesoft . They encoded one character of the path. WAF rules that looked for the literal string let the request pass, and PeopleSoft decoded it as usual. Mandiant found web shells and a backdoor it calls SIDEEYE on dozens of systems in higher education, healthcare, government, and other sectors. What the evidence confirms - In June, Mandiant notified more than 100 organizations whose IP addresses matched potentially vulnerable endpoints. Of these, 68% were universities and colleges. - Some of them blocked the attack. Others suffered a breach and saw stolen data on the leak site. - ShinyHunters also claimed it broke into the FBI jobs portal through PeopleSoft. The FBI later said the breach happened because a contractor failed to apply a security patch to a platform that a third party managed. Two sources told Reuters https://thehackernews.com/2026/10/fbi-removes-accenture-contractor-after.html the platform was PeopleSoft. The lesson for security teams Mandiant warned in June that WAF rules alone would not hold, and the September wave proved it. A WAF rule must decode a request the same way the application does, or an attacker can walk around it. Treat a virtual patch as a stopgap with an end date, and keep management endpoints off the public internet. 7. Klue: An old token and a tampered build A GitHub token left over from a 2022 trial project led to malicious code in production and stolen OAuth tokens for Klue’s customers. What happened Klue is a competitive intelligence platform that connects to its customers’ CRM and other business systems through OAuth. To do that, Klue stores OAuth tokens that give it access to its customers’ data. Klue’s CTO traced the intrusion https://klue.com/blog/what-a-security-incident-taught-us-about-securing-a-modern-saas-platform to a GitHub personal access token that the company created in 2022 for a trial project with a vendor and never revoked. The attack unfolded in two phases: 1. Quiet reconnaissance. The threat actor used the token to download source code, obtain a second token, and test other credentials. Nobody noticed. 2. A tampered build. Branch protection blocked a direct push to the main branch, but the attacker sent malicious code through a different build and deployment route. The tampered workload reached production and, within minutes, sent out integration credentials and stored OAuth tokens. The attacker then used the Salesforce tokens to query customers’ CRM data through the Salesforce REST API. What the evidence confirms - CrowdStrike’s review https://klue.com/blog/crowdstrike-investigation-summary-and-security-improvements confirmed this chain and found no attacker activity after Klue contained the intrusion on June 12. - HackerOne, Huntress, Jamf, LastPass, Recorded Future, and Tanium confirmed that the attacker reached their CRM or support data. Jamf warned its customers https://www.jamf.com/blog/klue-incident/ to expect phishing attacks built on the stolen contact data. - Klue told customers it reached an agreement with the attackers not to publish the data. - Neither Klue nor CrowdStrike could determine how the first token leaked. Press reports put the number of affected organizations near 200, but Klue has not confirmed that figure. The lesson for security teams An integrator that stores OAuth tokens holds a key to every customer at once, so a supply chain attack on one vendor reaches multiple companies. Revoke credentials when a trial project ends, and treat the CI/CD pipeline as part of production. Ask vendors how they store, scope, and rotate your tokens, and connect integrations through dedicated accounts with the least access they need. Our DevSecOps playbook https://equixly.com/blog/2026/04/20/how-to-build-api-security-into-your-ci-cd-pipeline-a-devsecops-playbook/ covers pipeline controls in more depth. 8. WordPress wp2shell: A batch endpoint as the way in Two flaws in WordPress Core looked minor on their own, but together they let attackers run code on websites without logging in. What happened The wp2shell chain combines two vulnerabilities in WordPress Core. CVE-2026-63030 is a route confusion bug in the REST API batch endpoint, and CVE-2026-60137 is an SQL injection in WP Query . Together, they give unauthenticated attackers remote code execution. Searchlight Cyber disclosed the chain https://www.slcyber.io/research/wp2shell-pre-authentication-rce-in-wordpress-core on July 17, the day WordPress shipped the fix https://wordpress.org/news/2026/07/wordpress-7-0-2-release/ . Public exploits followed within days. Neither vulnerability alone explains the damage. The route confusion flaw lets an unauthenticated request reach a code path it should never reach. The SQL injection then gives that request a way into the database. Public analyses https://www.elastic.co/security-labs/blog/wp2shell-wordpress-rce-detection-elastic-defend describe tools that use this access to gain administrator rights and upload a malicious plugin that works as a web shell. GreyNoise tracked one threat actor https://www.greynoise.io/blog/open-season-on-kapibala-attacker-steals-government-records-wordpress-exploitation , likely Chinese-speaking, who started to exploit wp2shell around July 20. In one intrusion against a Western government body, the actor: 1. Exploited the chain and installed a web shell. 2. Dumped 13 WordPress administrator accounts and added a fake one that imitated a real address at the target’s domain. 3. Tried at least 17 script variants to bypass Windows antimalware scans and gain higher privileges. 4. Found cleartext credentials for a backend SQL database in readable files. 5. Used those credentials to reach the internal SQL server and steal data. What the evidence confirms - GreyNoise counted at least 49 compromised organizations in 29 countries, mostly small businesses and government bodies. - At the government victim, the actor took at least 18,566 records with account details, plaintext passwords, and personal data tied to law enforcement and government agencies. The lesson for security teams Severity scores rate bugs one at a time, but attackers use them in sequence. A route confusion flaw that only misdirects a request looks modest on its own, and so does an injection point that an unauthenticated user should never reach. Together, they gave attackers code execution. Security tests need to follow the chain, not only score its links. The chain did not end at WordPress. Once on the server, the attacker found database passwords stored in plain text in files it could read, and used them to reach the internal SQL server. Passwords kept in a secrets manager instead of in readable files would have made that last step much harder. Batch endpoints deserve their own attention, because they bundle multiple requests into one and can skip checks that protect individual routes. The timeline matters too. WordPress shipped the fix on July 17, the actor GreyNoise tracked began attacks around July 20, and CISA added the chain to its Known Exploited Vulnerabilities catalog on July 21. For a platform this common, the time to patch shrank to days at most. 9. Gyazo: An upload server turned into a command line A vulnerability in Gyazo’s upload server exposed millions of user records and metadata for hundreds of millions of images. What happened On September 11, an attacker exploited a vulnerability in the image upload server of Gyazo, the screenshot service that Helpfeel runs. The flaw let the attacker run arbitrary commands on Helpfeel’s systems and reach the Gyazo database. Helpfeel detected https://corp.helpfeel.com/en/news/news-20260916 the activity that evening and closed the access routes by the early hours of September 12. It paused image delivery on September 14, later suspended the whole service, and resumed it on September 27. What the evidence confirms Helpfeel’s reports list what the attacker stole: - About 23.62 million user records with names, email addresses, password hashes, session and device IDs, X integration tokens, and Google SSO email addresses. About 18.01 million of these records belong to anonymous accounts without an email address. - About 490 million image metadata records , mostly for images uploaded in or before January 2019. The fields include image IDs, upload IP addresses, EXIF location data, and text that Gyazo extracted from images with OCR. - A list of private images , which means Helpfeel cannot rule out that someone viewed some of them. - Metadata for about 174 million images deleted before February 2023. These records describe the images; they do not contain the image files. No payment card data left the system. Helpfeel has not disclosed the type of vulnerability. The lesson for security teams Upload handlers parse files that strangers send, so they belong in isolation, away from the main data stores, with tight limits on what they can execute. The metadata deserves as much attention as the files. A single record can hold the upload IP address, location coordinates from a photo’s EXIF data when present, and the text OCR pulled from a screenshot, which may include whatever was on the screen at the time. When users deleted images, Gyazo kept metadata about them, which is how the attacker obtained metadata for about 174 million deleted images. Since image IDs also form the share links, anyone who holds them could try to open the images behind them. Links that rely on secrecy instead of access control turn a metadata leak into a content risk. 10. Times Car: Every stored ID adds to the damage Attackers reached the web system behind a Japanese car-sharing service and took identity documents for 1.6 million accounts. What happened Times Mobility, part of the Park24 group, detected unauthorized access to the web system behind its Times Car car-sharing service on September 25 and blocked it the next morning. In updates over the following days, the company confirmed that the attacker had taken personal information and identity documents. What the evidence confirms - About 6.6 million accounts https://www.bleepingcomputer.com/news/security/times-car-confirms-data-breach-affecting-66-million-user-accounts/ were affected, belonging to current and former members, people who never completed signup, and corporate users. - Personal data taken includes names, addresses, birth dates, phone numbers, email addresses, driver’s license details, and linked service IDs. Times Mobility, however, says it stored passwords in a form that cannot be restored. - Identity document images for about 1.6 million accounts were also taken: driver’s licenses, utility bills, student IDs, and family documents. No card data left the system. Times Mobility has not disclosed how the attacker got in, and it has warned customers to expect phishing emails, texts, and calls. The lesson for security teams The breach reached people who had left the service up to seven years earlier https://www.hokkaido-np.co.jp/article/1384883/ and people who never completed their signup. Each stored identity document adds to what an attacker can steal. Verify the document, keep the result of the check, and delete the image. Four patterns behind the top 10 web app attacks of 2026 Read side by side, the ten cases point to four patterns, each with a check that security teams can run. Trusted paths became attack paths A support ticket, a recovery chat, a guest profile, a build pipeline, and an OAuth grant all served as the way in. Each existed for a good reason, and most carried more access than their purpose needed. The check: Test as every identity, from anonymous visitors to support agents and connected services, and confirm what each one can reach. Flaws combined into chains wp2shell needed two bugs, and stored passwords carried the attack from the website to the database. At Klue, an old token led to the build pipeline and then to customer data. The check: Test whether weaknesses combine, not only how each one scores. Temporary defenses failed A single encoded character got past PeopleSoft WAF rules, and WordPress attacks began within days of the fix. The check: Treat a WAF rule as a stopgap until the patch lands, and retest after every release, permission change, or dependency update. Record counts measure size, not severity Gyazo’s breach was the largest by record count, but about 18.01 million of its 23.62 million records belong to anonymous accounts. The smaller Times Car and WFP breaches exposed more sensitive data: identity documents for 1.6 million accounts, and location details for about 600,000 households in a conflict zone. A record count shows how much data left the system, not how much harm it can cause. The check: Prioritize systems that hold sensitive information, such as identity documents, health records, financial data, or location data. Conclusion: Test the paths you trust The ten incidents hit ten different targets, from an ERP suite to an aid portal. Four began with flaws that a patch fixes. Four began with access that the application or its vendors had already granted: a guest profile, a recovery chat, a GitHub token, and an OAuth grant. Two victims have not said how the attackers got in. For the first group, speed matters most, as the PeopleSoft and wp2shell timelines show. For the second group, the defense starts with one question about every role, token, and endpoint: what can it reach, and should it? No cybersecurity program answers that question once and for all, because each new feature and integration changes the answer. Ask it again with every release. See which of your endpoints trust too much. Book a demo https://equixly.com/demo/ with Equixly.