deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

OfferBox configuration error exposed up to 314,009 students' names and emails

i-plug said a flaw in its OfferBox graduate recruiting service let employer accounts see student names and email addresses for more than three months, breaking the anonymity the product is built on.

OfferBox configuration error exposed up to 314,009 students' names and emails

What happened

On October 5, Japanese company i-plug disclosed that a configuration error in OfferBox, its job-matching service for university students, allowed employer accounts to see personal details that were supposed to stay hidden until a student accepted an offer. According to a write-up on dev.to, up to 314,009 students — the graduating classes of 2027 and 2028 — may have been affected.

OfferBox works by reverse-scouting: companies search student profiles and send offers, but a student's identity is revealed only when they accept. That asymmetry is the reason students sign up, and it is what makes this incident unusual. There was no attacker, no ransom demand and no stolen database. Instead, the data reached precisely the audience the platform had promised to shield it from.

How the exposure worked

Citing ITmedia's coverage of i-plug's announcement, the dev.to post explains that certain pages on the employer side of the site included student data in the communication payload — the data a server sends to the browser in order to render a page. Anyone who opened browser developer tools could see fields containing a student's family name, given name and email address.

There was one partial mitigating detail: the names were stored as character codes, in forms such as A4A2, and required a conversion step to read. As the dev.to author points out, that slows casual snooping but is not a security measure — character encoding is not encryption, and anyone curious enough to open developer tools is curious enough to decode a name. The email addresses were not encoded at all.

The flaw was live from May 12 to August 28. i-plug learned of it on August 27, the day after a client company reported seeing what appeared to be the name of a student who had not accepted any offer, and fixed the configuration the following day. In other words, the bug was caught by a customer report rather than the company's own checks, after more than three months in production.

Nobody knows how many records were viewed

i-plag's own framing, relayed in the reporting, is that 314,009 is a theoretical maximum: every student in the two graduating classes who was searchable during the window. The number actually viewed cannot be determined, because the data existed only in the payload and normal use never displayed it, so no access log records who inspected it. The company says only client companies could reach the affected pages, and that no outflow beyond client companies had been confirmed as of the announcement.

The dev.to author reads this not as a routine investigative hedge but as an honest statement about an unknowable quantity — and argues the cautious interpretation is the right one: students should assume their data was reachable for the full three months and act accordingly.

Advice for affected students

For 2027 and 2028 graduates who were searchable between May and August, the dev.to post recommends several practical steps. Expect recruiter contact that already knows your name, and treat unsolicited messages that seem unusually well informed with extra suspicion. Verify any communication claiming to come from OfferBox or i-plug by visiting the company's own site rather than following links in a message. Turn on multifactor authentication for the exposed email account, since that address is likely the recovery route for other services. Check Have I Been Pwned once the incident is indexed. The author also makes the case for using a dedicated email address per service, while conceding that an alias cannot protect the name itself, which the platform legitimately needed.

Why it matters

This incident defeated the central promise of the product. Students handed over identity data because they believed anonymity was technically enforced, and it was not. According to the reporting, i-plug's release process checked the displayed screen for stray personal data but never inspected the data underneath it — a gap that sounds obvious once stated, and one that many web applications share, since most ship data the interface never shows.

It also illustrates the limits of breach accounting. When leaked data lives only below the user interface, conventional access logs say nothing, leaving a company unable to tell affected users whether they were actually harmed. The dev.to author flags two open questions to watch: whether i-plug will notify affected students individually, and whether it will report the incident to Japan's Personal Information Protection Commission — neither of which was addressed in the announcement.

  • #privacy
  • #data-breach
  • #web-security
  • #recruiting
  • #japan

Related posts