ShinyHunters claimed 275 million records from Instructure's Canvas platform, which serves roughly 9,000 schools. If your institution runs Canvas, that single vendor incident touches coursework, rosters, and account identifiers for everyone who has logged in, and it did so without anyone breaching your own perimeter. This analysis draws on reporting from Huntress.

The group followed that up by defacing Canvas login portals at hundreds of institutions, timed to land during finals week. That timing matters operationally. When your learning management system is unavailable or visibly compromised during exams, you are managing grade integrity disputes, faculty escalations, and student communications at the worst point in the academic calendar.

Ninety days after the Canvas breach, the same group exploited an unpatched remote-code-execution flaw in Oracle PeopleSoft, reaching more than 300 instances at over 100 organizations, most of them universities.

PeopleSoft is where payroll, financial aid disbursement, HR records, and vendor payments live at most large institutions. Access at that layer puts your employee tax data, bank routing details, and student financial records in the same exposure as the academic data. Recovery involves forensic review of an ERP that your finance and HR operations depend on daily.

The data at stake across these incidents is broader than most people assume. Newcastle University's admissions misconfiguration exposed contact information for roughly 440,000 people, which includes applicants who never enrolled. Your institution likely holds records for applicants, current students, alumni, donors, and research collaborators going back decades, and every one of those populations enters your notification scope when an admissions or student information system is involved.

Student information systems concentrate that risk. The University of Western Australia incident involved credentials for Callista, its student information system, left reachable online by an administrator. A single set of credentials at that layer reaches enrollment, transcripts, and identity records for the entire student body, which is why your access review for SIS accounts carries different weight than it does for a departmental tool.

Compliance consequences arrive quickly and on multiple tracks:

• FERPA obligations attach to education records, which means exposure of enrollment, grade, or transcript data triggers review of your disclosure practices and student notification duties.
• State breach notification statutes apply where personal identifiers or financial data are involved, each with its own timelines and content requirements, and most institutions have affected individuals across many states.
• International privacy regimes apply when you enroll students abroad or operate campuses overseas, as the Avans University of Applied Sciences case in the Netherlands illustrates.

Exposure duration drives cost more than the initial finding does. At Avans, a Power BI misconfiguration exposed personal data to unauthorized viewers for nearly a year before anyone noticed. When you cannot establish who accessed what over a twelve month window, your legal counsel generally advises notifying the full affected population, which expands credit monitoring, call center staffing, and legal review well beyond what the technical facts might justify.

Universities are attractive because the data density is high and the tenure is long. Research programs hold grant-funded intellectual property and pre-publication work, alumni and donor databases hold giving histories tied to wealth indicators, and legacy platforms procured years ago by individual departments still hold live records. For your board, the practical translation is that a configuration error in one departmental dashboard can produce notification obligations, regulatory inquiries, and reputational coverage on the same scale as a targeted intrusion.

ShinyHunters' Attack Pattern Against Academic Institutions

The clearest technical marker in ShinyHunters' 2026 education activity is an unpatched remote-code-execution flaw in Oracle PeopleSoft, exploited roughly 90 days after the group's Instructure campaign. PeopleSoft runs human resources, finance, and student administration functions at large institutions, so code execution on that tier reaches payroll records, HR files, and financial data in one step.

That maps cleanly to T1190 (Exploit Public-Facing Application). The distinguishing detail is not the technique itself but the target selection. The group went after an internet-reachable enterprise application with a known, unremediated flaw, and it found the same unremediated flaw across hundreds of instances.

The other incidents this year did not involve exploitation at all. They involved access that was already available:

• Exposed administrator credentials. At the University of Western Australia, an administrator left system access credentials for Callista, the student information system, reachable online. That aligns with T1552 (Unsecured Credentials) followed by T1078 (Valid Accounts), and authenticated access through legitimate credentials produces log entries that look like normal administration.
• A misconfigured system connection. Newcastle University traced exposure of contact information for roughly 440,000 people to a single connection setting tied to its admissions system.
• A reporting platform left open. Avans University of Applied Sciences found a Power BI misconfiguration that exposed personal data to unauthorized viewers for close to a year before detection.

The Avans timeline is the number worth sitting with. Data was reachable by unauthorized parties for nearly twelve months with no alert, which means the exposure window was defined by when someone happened to look, not by any control. For an institution, that translates into a notification population you cannot bound precisely, because you do not know who accessed what during that period.

On exfiltration and monetization, ShinyHunters operates as a data-theft and extortion group. The visible outcome is a leak site listing with a sample posted publicly, followed by pressure on the institution. There is no encryption stage in these incidents, so the operational tell your teams would normally rely on, mass file modification and ransom notes, never appears. The first indication is often external.

Public reporting on these breaches has not published C2 domains, file hashes, or IP ranges, and that absence is itself informative. When initial access comes from a valid credential or an open connection setting, and collection happens through the application's own query and export functions, there is no implant to fingerprint. Detection has to come from access behavior rather than from a signature.

The throughline across the PeopleSoft campaign, the Callista credential, the admissions connection setting, and the Power BI dashboard is that an opening existed before any attacker got involved. Two of the four required no attacker tooling whatsoever. For security teams, that means the attack chain to recognize is authentication and query activity against student, HR, and finance systems from unexpected sources, not malware execution on endpoints.

Immediate Detection and Response Actions for University IT Teams

This Week

Turn on authentication logging everywhere it is off, starting with your student information system, admissions platform, and any business intelligence workspace publishing student or applicant data. The Avans University of Applied Sciences incident ran for nearly a year before anyone noticed a Power BI misconfiguration was exposing personal data, which is what happens when nobody is reading access records for reporting tools.

Once logging is on, hunt for the specific patterns that show up in exposure-driven breaches:

• Service accounts tied to SIS integrations authenticating from IP ranges outside your data center or vendor's published space
• Successful logins to admin consoles with no preceding MFA challenge, which usually means an exemption or legacy protocol path is still live
• Dashboard and report objects with sharing set to "anyone with the link" or published to web, particularly in departmental workspaces
• Bulk export or query volumes from student-record and alumni databases outside registration and billing cycles

Pull a list of every account with administrative rights on those systems and confirm each one still belongs to a current employee with a current reason. The University of Western Australia found an administrator had left Callista access credentials reachable online, so also search your public code repositories, wikis, and shared drives for connection strings and API keys.

Next Two to Four Weeks

Review VPN and remote access logs against your directory. Universities carry large populations of contractors, visiting researchers, and adjuncts whose accounts outlive their appointments, and those accounts are a reliable path into departmental systems that never got covered by central controls.

Enforce MFA on the administrative tier of every system holding regulated data, not only on faculty and staff email. Adlumin watches authentication behavior across the environments Capstone manages, flagging impossible-travel logins and off-hours administrative sessions in academic environments where legitimate access already comes from many countries and time zones.

Build an inventory of where sensitive data actually sits. List each admissions, financial aid, health services, and research repository, the vendor connections feeding it, and the person who owns that connection. Newcastle University traced exposure of contact information for roughly 440,000 people back to a single connection setting, and you cannot review settings on integrations you have not written down.

One to Three Months

Extend endpoint detection to the servers running your administrative applications, including the departmental machines that IT inherited rather than provisioned. Coverage gaps in higher education tend to sit in colleges and labs that bought their own hardware.

Segment research computing away from student records and finance. Research networks are built for collaboration and often carry looser access rules, so a compromise there should not reach the systems that hold Social Security numbers, transcripts, and payment data.

Then set a recurring configuration review rather than a one-time cleanup. Assign an owner for each third-party integration, require a security check before any new dashboard or data connection goes live, and run a quarterly sweep for externally reachable services and open sharing permissions. Decentralized governance is not going away, so the practical goal is continuous visibility into what is exposed across departments, with someone accountable for reading the findings.

Regulatory and Notification Obligations for Breached Universities

Newcastle University's admissions misconfiguration exposed contact information for roughly 440,000 people. That number is the notification population, and it is the figure that drives every cost and deadline that follows. Postal notice, call center capacity, credit monitoring offers, and regulator correspondence all scale with it.

FERPA governs how your institution handles education records, and it requires you to maintain a record of unauthorized disclosures for the students affected. What FERPA does not give you is a notification clock. That clock comes from state breach notification statutes, and the jurisdiction that applies is determined by where your data subjects live, not where your campus sits.

For a university with out-of-state undergraduates, online learners, and alumni scattered across the country, that means one incident can trigger obligations under dozens of state regimes at once. Timelines differ. Some states set a fixed number of days from discovery, others require notice without unreasonable delay, and several add a separate filing to the state attorney general once the affected count crosses a threshold. Your legal team has to map the residency spread of the exposed records before it can tell you when the earliest deadline lands.

International students and staff widen it further. The Netherlands and Australia incidents this year answered to their own national data protection regulators, each with its own reporting expectations and its own view of what counts as adequate mitigation. If you enroll students from the EU or UK, a single exposed admissions feed puts you in front of a supervisory authority on a timeline that is considerably shorter than most US state statutes.

Two additional regimes catch institutions by surprise. If you participate in federal student aid programs, the financial aid records you hold fall under the GLBA Safeguards Rule, which carries reporting expectations of its own and can surface later in a Department of Education program review. If your researchers hold federal contracts involving controlled unclassified information, those agreements typically contain incident reporting clauses with their own deadlines, entirely separate from the student privacy track.

The people who need to be in the room are wider than the incident bridge:

• General counsel, who owns the multi-jurisdiction deadline analysis and the privilege posture of the investigation
• The registrar or FERPA compliance officer, who determines which fields actually constitute education records
• Communications and enrollment management, since applicants mid-cycle read breach notices differently than alumni do
• Your cyber insurance carrier, whose policy usually conditions coverage on prompt notice and approved counsel
• The board or governing body, which will be asked what oversight existed before the exposure

Vendor-side exposure does not shift the duty. When the gap sits in a third-party admissions connection or a hosted dashboard, the vendor may hold the technical facts, but your institution remains the entity that owes notice to the individuals whose records were exposed. Your contract determines whether you can recover costs afterward, and it rarely determines who has to send the letters.

The enrollment consequences arrive on their own schedule. Applicants in an active cycle, families deciding on deposits, and donors evaluating a gift all encounter the disclosure as a data point about institutional competence. EDUCAUSE and higher-ed information sharing groups circulate peer guidance on how institutions have handled these disclosures, which is useful context when your communications team drafts language your board will have to defend.

Securing Legacy Systems Common in Academic Networks

Start with network segmentation on the systems you cannot patch. Put each legacy student information system, research data store, and finance application on its own VLAN with a deny-by-default rule set, and require access through a jump host that enforces MFA. Legacy platforms will keep accepting weak protocols no matter what you do, so the control has to sit around the system instead of inside it.

Order the work by what an attacker can monetize and what a regulator will ask about. Student data systems come first because they hold identifiers for people who never chose your vendor. Financial and payroll platforms come second, because a compromise there produces fraudulent disbursements as well as a disclosure. Research repositories come third for most institutions, with the exception of anything covered by a sponsor's security terms or export control requirements, which jumps to the front.

Credentials are the piece most often left half-finished. The University of Western Australia case involved administrator credentials for its Callista student information system sitting exposed online, which is a reminder that legacy platforms tend to accumulate accounts nobody has audited in years. Work through the account list on each prioritized system and do three things:

• Delete shared departmental logins and issue named accounts, even if it means more license seats or more entries in a local user table.
• Inventory service accounts and integration credentials, rotate them, and record which vendor or script uses each one so rotation stops breaking things.
• Remove local administrator rights from staff who only need read access to reports, and re-scope roles so a records clerk cannot query the full student table.

Where the application predates role-based access entirely, enforce the restriction at the database layer or through a reverse proxy that filters requests by path and user group. It is coarse, but it caps what a single compromised login can pull.

For systems that cannot take a patch or a modern agent, move monitoring up to the application layer. Forward application and database logs to your SIEM, then write detections for the behaviors that matter on those specific platforms: bulk record exports outside business hours, queries returning row counts far above the daily norm, schema or stored procedure changes, and any authentication to an admin account that has been dormant. Web application firewall rules in front of legacy web front ends will also block generic injection attempts against code no vendor will fix.

Recovery deserves attention that legacy systems rarely get, because you often cannot rebuild them from vendor media. Original installers, license keys, and the staff who understood the configuration may all be gone. N-able Cove maintains image-level backups of these older workloads across managed environments, so a failed or compromised host can be restored as a whole machine instead of reconstructed from documentation nobody wrote.

None of this requires replacing the platform. Segmentation, named accounts, layered access control, log-based detection, and a tested restore path can be delivered on systems that will stay in service for several more budget cycles. Document each compensating control against the specific weakness it covers, and review that mapping when the vendor announces an end-of-support date so replacement planning starts before the controls become your only defense.

Next Steps: Threat Intelligence Sharing and Sector Coordination

Each of this year's higher ed disclosures was reported as its own story. That framing is a reporting artifact, and it works in the attacker's favor, because the same vendor connection or exposed reporting workspace that opened one institution is probably sitting in the same state at a dozen others.

The single most useful thing you can do after an incident is tell other people about it. Submit indicators to your sector information sharing body, such as REN-ISAC for research and education institutions, and file with the FBI's Internet Crime Complaint Center (IC3). CISA publishes advisories on the same public-facing platforms your institution runs, and those advisories only stay current because organizations report what they found.

Peer coordination matters more in higher education than in most sectors because you share vendors. If a neighboring university tells you which integration setting was wrong on their admissions platform, you learn something about your own environment that no scanner will surface for you. Consortium security groups, state system offices, and regional peer networks are the practical channels for that conversation.

ShinyHunters is an organized extortion group with a track record of returning to the same sector on a repeating schedule. Sharing what you observed shortens the window for everyone the group targets next, including you.

Breaches driven by exposed credentials and misconfigured connections are preventable with known technical controls and reasonable detection coverage. Institutions that report what they find, and read what their peers report, narrow the set of openings available to the next group that goes looking.