On October 5, i-plug announced employers using its student job service OfferBox could see names and email addresses they were never meant to see. Up to 314,009 students, the 2027 and 2028 graduating classes, may have been exposed. You handed a platform your identity because it promised to keep it. I run AliasFleet: one unique email address per site, so when a platform breaks its own rules, the address it hands out belongs to that platform alone.
This one cuts differently from the breach stories I usually cover. There was no hacker, no ransom note, no stolen database. The exposure was a configuration error on a product whose entire selling point is confidentiality.
The promise was the product
OfferBox is a reverse-scouting service for new graduates, and its pitch to students is built on one promise. Companies search for students they like and send them offers, but a company does not learn your name until you accept its offer. That asymmetry is the reason to sign up: students can explore employers without employers knowing who is looking.
That is what makes this incident land so hard. The platform did not lose data to criminals. It handed data to the exact people it had promised to keep it from. Not every student, not confirmed viewed, but the mechanism that was supposed to prevent it simply was not there.
How the flaw worked
According to ITmedia's report on i-plug's announcement, certain pages on the employer side of the site included student data in the communication payload, the data the server sends to the browser to render the page. Open the browser's developer tools and it was right there: the student's family name (LASTNAME), given name (FIRSTNAME), and email address (LOGINID).
One detail worth pausing on. The names were not sitting in plaintext. They were character-code encoded, rendered as codes like A4A2, and you needed a conversion tool to turn them back into a name. That slowed casual viewing, but it is not protection. Encoding is not encryption, and anyone curious enough to open dev tools is curious enough to decode a name.
The email addresses were not encoded at all.
The flaw ran from May 12 to August 28, more than three months. i-plug found it on August 27, the day after a client company reported seeing what looked like the name of a student who had not accepted any offer. It fixed the configuration the next day. Three months of exposure, caught by a customer report, not by the company's own checks. I will come back to that, because it is the most instructive part of this story.
The honest unknown: 314,009 is a ceiling
Here is what I want to be straight about. The number 314,009 is the theoretical maximum: every 2027 and 2028 graduate who was a search target during the exposure window. It is not the number of students whose data was actually viewed, and nobody knows that number. i-plug says so itself.
The reason is structural. The data existed only in the communication payload, and in normal use employers could not see it, so there is no access log of who opened dev tools and who did not. The company says the actual number of viewed students cannot be determined, and that only client companies could access it. No outflow beyond client companies has been confirmed as of the announcement.
This is not the usual "we are still investigating" hedge. It is an honest statement about an unknowable quantity, and the correct reading is also the cautious one: assume your data was accessible for three months and act accordingly. A ceiling is still a real number when the floor is unknown.
Why this one stings for students
The email field here is the LOGINID. For most students, that is their main email address, the one tied to their bank, their social accounts, their password resets. A job service is exactly the kind of place you hand your real address without thinking, because recruiters need to reach you.
These are 2027 and 2028 graduates. Early in their careers, filling out profiles across a dozen job platforms, each one asking for the same details. The career stakes make the privacy failure worse: a name tied to a job search carries context that a random email in a retail database does not. An employer who saw a student's name and email outside the agreed process holds information the student chose not to share, and the student has no way to know who saw what.
And there is the promise itself. OfferBox's non-disclosure pledge is not a side feature. It is the product. Students signed up because of it. i-plug told them, in effect, that anonymity-until-acceptance was technically enforced. It was not. The release process checked the displayed screen for stray personal data but never checked the data underneath the screen. That is the kind of gap that sounds absurd once stated, and it survived three months of production use.
What to do if you are on OfferBox
If you registered as a 2027 or 2028 graduate and were searchable between May and August, assume your name and email were in the payload. Here is the practical response:
- Expect contact that knows your name. The exposure reached employers, not criminals, but data travels. Treat unsolicited recruiter emails, calls and messages with extra care for a while, especially ones that seem to know your job search too well.
- Verify anyone claiming to be OfferBox or i-plug. If a message about this incident arrives, go to the company's own site yourself. Do not follow its links.
- Separate your job-hunting identity if you have not. If your OfferBox login email is also your bank, your social accounts and your everything else, the exposure touches all of it. You do not need to panic, but you should not let one leaked address be the key to every account you own.
- Lock down the inbox anyway. Turn on multifactor authentication on your email account. Your address is the recovery route for everything else.
- Check Have I Been Pwned once the breach is listed. It is the canonical place to see which of your addresses have leaked and where.
The breach-response guide has the full checklist in order, so start there.
The address that names its source
Here is the honest version of the alias argument, including the part that does not work.
An alias cannot make a job hunt anonymous. Recruiters need your real name, your real history, your real contact details. If you had signed up for OfferBox with an alias, the leaked email address would have belonged to your job search alone: pause or delete it and the whole attack channel dies, while your real inbox stays clean. That part is true and useful.
The name part is not fixable by an alias. The platform needed your name, and the flaw exposed it. No addressing trick changes that. So do not let anyone sell you total protection here. What an alias buys is containment of the address, the one piece of the leak that follows you forever and unlocks everything else. When the next platform breaks its promise, and one will, the email in the payload is a fingerprint that names the source. That is the leak-tracing mechanism working as designed, and it is the only part of a privacy failure you get to control before it happens.
If you have never used one: this is what an email alias is. Two minutes to set up: the guide.
Two things I am watching
First, whether i-plug notifies affected students individually, and whether it reports to Japan's Personal Information Protection Commission. The announcement covered neither in the reporting I read. A company that cannot identify the viewed students owes the unknowable set something better than silence.
Second, whether the "check the payload, not just the screen" lesson spreads. This flaw is not exotic: every web app ships data the UI does not display, and plenty of release processes only eyeball the screen. The testing gap that let this run for three months is the kind of ordinary negligence that produces most exposures, and I expect more stories like this one.
One last thought. i-plug's promise was enforced by a checkbox in a release process, and the checkbox was pointed at the wrong layer. The students kept their end of the bargain. The code did not.
Top comments (0)