UC Berkeley EECS systems security incident

Analyst assessment

DysruptionHub assesses with high confidence that the University of California, Berkeley experienced a confirmed cyber incident affecting Department of Electrical Engineering and Computer Sciences infrastructure. The university’s Sept. 2 security update said endpoint detection and response software identified suspicious activity across EECS systems. Campus IT restricted network access and took several systems offline. This is concrete cyber-specific evidence, but it does not establish the nature of the activity or show that an attacker gained persistent or unauthorized access.

In a Sept. 4 response to our questions, campus spokesperson Janet Gilmore said comprehensive EECS containment efforts began Aug. 26. She said the activity had not been attributed to any known threat actor and that investigators were examining whether data may have been exposed. Gilmore later confirmed to The Daily Californian that UC Berkeley reported the incident to law enforcement, but she did not identify the agency. The response did not say when the activity began or was first detected, whether access was unauthorized, what mechanism was involved or whether exposure had occurred. The public record does not support confirmed ransomware, extortion, data theft or attribution. A ShinyHunters incident involving UC Berkeley’s Canvas environment in May 2026 is a separate event and is not treated as evidence about this EECS incident.

Operational significance

EECS provides instructional and research computing for a major public university. We reported that a Unix login server went offline Aug. 18 and was slated for replacement before the department’s IRIS status page reported all services down Aug. 25, affecting home-directory storage, project storage, the IRIS website and Unix login services. Gilmore said comprehensive containment began Aug. 26. A separate Aug. 28 status entry said wired-network DHCP service had been restored, although messages sent to the department’s help address might not be received. The broader Aug. 25 outage item remained categorized as active when reviewed Sept. 4. UC Berkeley did not answer whether the Aug. 18, Aug. 25 or Aug. 28 service events were connected to the suspicious activity. The university has not linked the Aug. 18 outage to the later security response, so DysruptionHub does not treat it as an established start date for the cyber incident.

The university said faculty and staff disruptions resulted from protective campus actions, alternative access pathways and workarounds were provided, and system restoration was gradual. It said instructional services were restored quickly to reduce the effect on courses and central campus IT services were not affected.

The Daily Californian reported that an anonymous AI lab director said access to some internal research environments was disrupted when data centers were taken offline, with most operations restored quickly or moved to Amazon Web Services. Sources familiar with the outage identified Warren Hall computers supporting the Savio cluster among affected systems. DysruptionHub treats those details as attributed reporting rather than a university-confirmed inventory of affected infrastructure. The evidence therefore supports a meaningful but contained department-level disruption involving unavailable internal systems, network restrictions, alternate access and some educational impact; it does not establish a campuswide outage.

The department’s webservice restoration log documented a staged recovery: NFS file access and most hosted websites had returned Sept. 9, followed by intermittent performance and DNS problems Sept. 10. By Sept. 15 at 4 p.m., department-hosted websites and personal pages were reported working. Separate mailing-list and network-and-roster services were still being worked on at that point. These updates establish recovery of specific functions, not a complete departmental all-clear.

Confidence and uncertainty

Confidence is high that suspicious activity triggered a security response and disrupted EECS systems because the university documented both the endpoint-security detection and its containment actions. The direct response establishes with high confidence that comprehensive containment began Aug. 26. Confidence remains medium on the relationship between the Aug. 18, Aug. 25 and Aug. 28 EECS service events and the security response because Berkeley did not answer whether they were connected and the earlier status posts did not identify a cyber cause. The Aug. 28 DHCP restoration demonstrates partial recovery of an EECS network function but does not establish restoration of all affected systems.

Ransomware and threat-actor attribution remain unresolved. Searches using the university’s canonical name, common name and berkeley.edu domain did not identify a stable ransomware or extortion claim tied to this EECS event. Gilmore also said no known threat actor had been linked to the activity.

Analytic gaps

The public record does not establish when the suspicious activity began or was first detected; whether the Aug. 18, Aug. 25 or Aug. 28 service events were connected to it; whether access was unauthorized; the initial access vector; any exploited vulnerability; the affected endpoints or accounts; the persistence or lateral-movement scope; or whether malware was present. It also does not establish whether data was accessed, copied, altered or exposed; whether a ransom demand or extortion communication occurred; which law-enforcement agency received the report; or when every affected EECS service will be fully restored.

Current status

Recovery has been phased, without a complete departmental all-clear. The latest dated restoration notice was Sept. 17. The EECS IRIS status page said the department’s mailing-list server had returned to service after earlier staged restoration of network and storage functions. The page did not provide a complete all-clear for every system affected by the security response.