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:
- Four began with a code flaw , such as remote code execution or stored XSS.
- Four began with a logic vulnerability, a misconfiguration, or a stolen token . The request the attacker sent looked legitimate to the application.
- 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:
- Confirmed malicious activity. The victim, a regulator filing, or published forensic research confirms the attack. A hacker’s claim alone did not qualify.
- A web application at the center. The attacker went after a web application or the services and integrations behind it.
- A 2026 attack. The incident took place in 2026.
- 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 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:
- Took over the employee’s Google Workspace account.
- Used it to enter the employee’s Vercel account.
- Moved into a Vercel environment.
- Listed and decrypted environment variables that customers had not marked as sensitive.
According to researchers at Hudson Rock, 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.
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 . 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 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 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 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, 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 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 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. 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. The attacker then used the custom themes feature to place a ransom note on the login pages of roughly 300 institutions (The Register 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 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 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 recipients through Telegram on May 31. It restarted the application 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 .
- 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 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. 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 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 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:
- Quiet reconnaissance. The threat actor used the token to download source code, obtain a second token, and test other credentials. Nobody noticed.
- 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 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 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 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 on July 17, the day WordPress shipped the fix. 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 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, likely Chinese-speaking, who started to exploit wp2shell around July 20. In one intrusion against a Western government body, the actor:
- Exploited the chain and installed a web shell.
- Dumped 13 WordPress administrator accounts and added a fake one that imitated a real address at the target’s domain.
- Tried at least 17 script variants to bypass Windows antimalware scans and gain higher privileges.
- Found cleartext credentials for a backend SQL database in readable files.
- 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 the activity that evening and closed the access routes by the early hours of September 12. It d 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 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 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 with Equixly.