Elsevier's domain record sat unchanged for 342 days, yet three of its addresses went to a LAPSUS$-branded page

The record did not move. The name did.

The registry record for elsevier.com was last changed on 14 October 2025. The redirect that put three Elsevier web addresses in front of a LAPSUS$-branded page was first reported on the evening of 21 September 2026. That is 342 days in which, by the registry's own date, the domain record did not change, and it carries three registrar locks: delete, transfer and update prohibited. You can check it with a WHOIS or RDAP lookup on the .com registry. I ran both on 29 September 2026 and they agree.

The three names were the company's main site, a sign-in and learning platform for nursing and health-professions education, and the portal where researchers submit manuscripts, as Help Net Security describes them. Cloudskope, a firm that checked them directly, reports that all three sent visitors to another page for at least 78 minutes.

What that does not establish. It does not say which layer moved: a DNS record, a rule at the web edge, or the account that manages either. It does not say how the access was obtained, who used it, how many people saw the page, or whether any data or credentials were touched. And it is a record read after the event, so it shows what a lock covers and what it does not, not what happened inside Elsevier.

What Elsevier has said, and the words it leaves out

Elsevier's whole public account is a 66-word, four-sentence statement, carried word for word by The Register, Help Net Security and teiss. It says that on 21 September the company "identified that visitors to select platforms were being redirected to a third-party page", that its team resolved it, and that there is "no indication that core platforms, customer data, research content, or operational systems were compromised".

Read for what a customer would need, it is bare. It contains no start time, no end time, no hostname, no cause and no name for the group. The word "attack" does not appear, and "compromised" appears once, in the sentence reporting that no indication of it was found. The Register's headline calls this a LAPSUS$ redirect attack. That framing comes from the brand on the destination page, and Elsevier has not adopted it.

Elsevier did not answer The Register's follow-up questions on which platforms were affected and for how long, or Cloudskope's seven questions by its deadline. On 29 September I found no mention of the incident in the HTML of Elsevier's or RELX's press-releases pages or the Evolve landing page, though scripted content could hide one.

What the record fixes and what it does not

Six questions, sorted by what the sources establish. Sources: Elsevier's statement as carried by The Register, Help Net Security and teiss; Cloudskope; Securonix; the author's registry and DNS lookups.

Question	Fixed on the record	Not established
What was redirected	www, evolve and submit at elsevier.com returned an HTTP 302 to an external page (Cloudskope). ScienceDirect loaded normally.	Which platforms, in Elsevier's own words. A claim that a drug-database API was also redirected is unconfirmed.
For how long	Two names live at 8:17 pm Central, all three by 9:07 pm, clear at 10:09 pm. A forum post puts it at about 7:49 pm.	The real start and end. Elsevier gave neither.
Data and credentials	Elsevier: no indication customer data was compromised. Nobody has claimed Elsevier data (Cloudskope, 24 September).	What the account that changed the routing could reach. "No indication" is what an investigation found, not what was possible.
Who	A signed statement on the page verifies against a published key (Securonix, high confidence).	Who holds the key, whether that person changed Elsevier's routing, and any link to the 2021 to 2022 group (low confidence).
How	None of the sources reports a software flaw. Three names hit and ScienceDirect not fits a change at the DNS or edge layer (Cloudskope's inference).	Which layer, account or credential. A forum post claims altered Cloudflare redirect rules; Cloudskope could not verify it.
How many people	One student's screenshot is quoted by The Register. Cloudskope holds one recording.	Any count. teiss says "thousands of students"; no source gives a figure.

Seventy-eight minutes is a floor with a forum post under it

The figure in the coverage, at least 78 minutes, is arithmetic on Cloudskope's timeline. It runs from about 7:49 pm Central, when a Chinese-language forum post reported the redirect, to 9:07 pm, the last time Cloudskope saw it live. Cloudskope's own first-hand checks begin at 8:17 pm, which gives 50 minutes. The end is only bracketed: the redirect cleared at some point between 9:07 and 10:09 pm.

Derived arithmetic on Cloudskope's timeline for 21 September 2026, Central Time. Elsevier has confirmed none of these times.

Basis	Window	Minutes
Cloudskope's own live checks	8:17 to 9:07 pm	50
Adds a student's recording, held by Cloudskope	7:57 to 9:07 pm	70
Adds the forum post: the headline figure	about 7:49 to 9:07 pm	78
Ceiling, if the forum post marks the true start	about 7:49 to 10:09 pm	140

The ceiling is fragile, because the forum post reports a redirect already in place, so the start may be earlier.

Elsevier's statement adds a clue its authors probably did not intend. It says Elsevier identified the redirect on 21 September. Cloudskope's times are Central, five hours behind UTC in September. The first sighting, 7:49 pm, is 00:49 UTC on 22 September, and 01:49 in the UK. On UTC or any European clock, the earliest published sighting is already the 22nd. So either Elsevier's "21 September" is a US-time date, or the redirect began before the first sighting anyone has published. The statement does not say which. That is inference.

The same conversion puts the whole reported window between 01:49 and 04:09 UK time, in the small hours of a Tuesday. The first public reports came from outside the company, a forum and a student. Whether Elsevier's own monitoring saw it first is not stated.

Where a redirect can live

A "redirect attack" is not a category of breach. It is what happens when someone changes where a name points, and there are at least three places to do it between the address bar and Elsevier's servers. The diagram sets out what public lookups show for the three affected names today.

The registry layer is the one people mean by "locked". Elsevier's record carries the standard registrar locks and no registry-level lock. Those locks stop unauthorised changes to the registration: name servers, contacts, a transfer. They do not stop anyone with access to the DNS zone from editing a record, or anyone with access to the web-edge account from adding a rule, and neither touches the registry.

The other two layers are where the record is thinner. Today, www and evolve are CNAME records in a zone served by the reedelsevier.com name servers, which relx.com also uses, pointing at Cloudflare hostnames, while submit is delegated outright to Cloudflare's name servers. Three names, two arrangements, one common provider. ScienceDirect, which was not redirected, is served through Cloudflare too, so "uses Cloudflare" does not explain who was hit. The three redirected names share the elsevier.com parent, not a provider, which suggests something scoped to that domain rather than a company-wide credential. That is inference.

Cloudskope saw an HTTP 302 with a Location header. A 302 is what a redirect rule at the web edge returns, and it is the simpler fit for one change hitting three names in two DNS arrangements: a rule in one place. A DNS edit could also do it, by pointing the names at a server that answered for Elsevier's name, but that takes more work. This is my reading of public records, not a finding, and only audit logs at Elsevier or its providers could settle it. No source alleges a flaw in Cloudflare or any other provider, and a redirect rule doing what it was built to do is not one.

The name on the page is not the name on the change

The headlines I found all attach the LAPSUS$ name. Elsevier's statement attaches none. A brand on a page is not an identity, and this one has belonged to more than one set of people: the group of 2021 and 2022 whose members were arrested, a 2025 collective that used the name alongside others, and a 2026 leak-site persona that Help Net Security says named victims including Virta Health, Vodafone Germany and AYA Bank. Securonix, which analysed the destination page and verified its signature, puts continuity with the original group at low confidence and writes that the evidence "supports continuity of persona and narrative more strongly than continuity of personnel".

A valid signature shows only that whoever holds a private key wrote the statement. It does not show who that is, and it says nothing about who changed Elsevier's routing. They may be the same party. No source I read shows it. The page had been staged since 2 September, 19 days before the redirect, and Securonix had published on it a week earlier. Anyone able to change where the names pointed could have chosen it, and Securonix lists opportunistic impersonation among three operator models it considers possible. Cloudskope hypothesises that credentials stolen in an earlier supply-chain campaign were used, and says itself that no public evidence ties the change to any specific credential. I have built nothing on that.

The "no payload" reassurance needs a caution too. Securonix's finding is about the version it hashed: a 10,977-byte page with a countdown to 12 September. The page served at that name when I read it on 29 September is a different object, 14,987 bytes with a different SHA-256 digest. Cloudskope's account of what visitors saw on 21 September includes a listed victim and a fresh countdown, which Securonix's description of its version does not. So the page changed in between, and I found no published analysis of the later version.

I read the current HTML as text and did not run it: one inline script, no form, no frame, no network call, consistent with Securonix. Its countdown restarts at the same span on every load, so it is decoration, not a schedule. That describes 29 September, not 21 September. I do not link to the page.

What a redirect to a static page can and cannot take

The advice for students, to change a password if they signed in during the window, is sensible caution, but the record supports something narrower. A redirect sends the browser to a different address. The destination Securonix analysed had no form, the version I read has none either, and a browser does not send cookies for elsevier.com to another domain. On the record, a visitor who followed a link saw a page and had nothing to type into. A redirect alone is not a personal data breach either; it becomes one only if personal data was accessed or disclosed, which no source states.

The exposure that remains is the one the statement is silent on. Whoever could set a redirect held an account on a layer that carries all traffic to those names. What else it could do, and whether it did, is a question for logs only Elsevier holds. "No indication" reports what an investigation has found, not what was possible.

For programmatic clients the concern is sharper. DataBreaches.net relays a claim by Sorami Consulting that token requests to a drug-database authentication endpoint were redirected. Nobody has confirmed it and Cloudskope did not test it; I could read only the item's excerpt, because the page sits behind a bot check I did not try to bypass. It is still worth asking suppliers about, because an API client that follows a redirect on an authentication call may send its request wherever it is told.

Who is telling you this

Most of what is known about timing and pattern comes from one firm. Cloudskope is a commercial advisory business whose own pages sell DNS, CDN and registrar assessments. That is no reason to doubt its measurements, and it is a reason to remember it has a commercial interest in the risk being taken seriously. It says its earliest recording came through a personal connection to one of its analysts, and I found no published copy. Securonix sells security analytics and analysed the page a week before the redirect, not the redirect. Elsevier has an obvious interest in "narrowly scoped" and "limited-duration", and has withheld the two facts, platforms and duration, that would let anyone test those words. The press coverage carries the same statement and adds nothing first-hand about the mechanism.

What to do, in order

The question to answer before the next one

Key facts