elesin

Starting on Monday night, users began reporting a mass outage at the 4chan.org domain, which has persisted for the last 12 hours, according to Downdetector.com.

But during the outage, users spotted evidence that 4chan suffered a breach that enabled a hacker to gain access to the site. This includes a screenshot that apparently shows an account from 4chan’s owner Hiroyuki Nishimura writing: “LOL HACKED I LOVE DICKS.”

Another post from the hijacked Nishimura’s account indicates the hacker gained access to the backend administrative site for 4chan. The same screenshot shows that 4chan runs on an old version of PHP, a scripting language for websites.

As a result, users suspect the hacker exploited age-old vulnerabilities in 4chan to conduct the takeover. A rival imageboard at Soyjak.party has also been celebrating the site’s shutdown.

t’s possible someone at Soyjak.party was involved in the hack since the 4chan board for questions and answers was briefly changed to say “SOYJAK.PARTY WON.” The Soyjak.party site has also been posting screenshots that show the hacker was able to access moderator functions for 4chan. This includes accessing the ability to ban 4chan users, revealing their IP address, ISP, and geographic location.

In addition, links have appeared on Soyjak and on another web forum, Kiwi Farms, that claim to contain data stolen from 4chan, including the usernames and email addresses for hundreds of moderators. So, it’s possible the hacker may have stolen email address information for all registered users of the site.

Cybersecurity researchers are warning of a new type of supply chain attack, Slopsquatting, induced by a hallucinating generative AI model recommending non-existent dependencies.

According to research by a team from the University of Texas at San Antonio, Virginia Tech, and the University of Oklahama, package hallucination is a common thing with Large Language Models (LLM)-generated code which threat actors can take advantage of.

“The reliance of popular programming languages such as Python and JavaScript on centralized package repositories and open-source software, combined with the emergence of code-generating LLMs, has created a new type of threat to the software supply chain: package hallucinations,” the researchers said in a https://arxiv.org/pdf/2406.10279.

From the analysis of 16 code-generation models, including GPT-4, GPT-3.5, CodeLlama, DeepSeek, and Mistral, researchers observed approximately a fifth of the packages recommended to be fakes.

According to the researchers, threat actors can register hallucinated packages and distribute malicious codes using them.

“If a single hallucinated package becomes widely recommended by AI tools, and an attacker has registered that name, the potential for widespread compromise is real,” according to a Socket analysis of the research. “And given that many developers trust the output of AI tools without rigorous validation, the window of opportunity is wide open.”

Slopsquatting, as researchers are calling it, is a term first coined by Seth Larson, a security developer-in-residence at Python Software Foundation (PSF), for its resemblance to the typosquatting technique. Instead of relying on a user’s mistake, as in typosquats, threat actors rely on an AI model’s mistake.

A significant number of packages, amounting to 19.7% (205,000 packages), recommended in test samples were found to be fakes. Open-source models –like DeepSeek and WizardCoder– hallucinated more frequently, at 21.7% on average, compared to the commercial ones (5.2%) like GPT 4.

Researchers found CodeLlama ( hallucinating over a third of the outputs) to be the worst offender, and GPT-4 Turbo ( just 3.59% hallucinations) to be the best performer.

These package hallucinations are particularly dangerous as they were found to be persistent, repetitive, and believable.

When researchers reran 500 prompts that had previously produced hallucinated packages, 43% of hallucinations reappeared every time in 10 successive re-runs, with 58% of them appearing in more than one run.

The study concluded that this persistence indicates “that the majority of hallucinations are not just random noise, but repeatable artifacts of how the models respond to certain prompts.” This increases their value to attackers, it added.

Additionally, these hallucinated package names were observed to be “semantically convincing”. Thirty-eight percent of them had moderate string similarity to real packages, suggesting a similar naming structure. “Only 13% of hallucinations were simple off-by-one typos,” Socket added.

While neither the Socket analysis nor the research paper mentioned any in-the-wild Slopsquatting instances, both cautioned protective measures. Socket recommended developers install dependency scanners before production and runtime to fish out malicious packages. Rushing through security testing is one of the reasons AI models succumb to hallucinations. Recently, OpenAI was blamed for slashing its models’ testing time and resources significantly, exposing its usage to significant threats.

Oracle has continued to downplay a data breach it suffered earlier this year, insisting in an email sent to customers this week that the hack did not involve its core platform, Oracle Cloud Infrastructure (OCI).

Normally, a denial like this would be the end of the story, but the circumstances of this breach and Oracle’s confusing response to it over recent weeks have left some questioning the company’s account of the incident.

This week’s email, forwarded to this publication by Oracle, claimed that the incident involved “two obsolete servers” unconnected to the OCI or any customer cloud environments.

“Oracle would like to state unequivocally that the Oracle Cloud — also known as Oracle Cloud Infrastructure or OCI — has NOT experienced a security breach,” stated the letter.

“No OCI customer environment has been penetrated. No OCI customer data has been viewed or stolen. No OCI service has been interrupted or compromised in any way,” it continued.

No usable passwords were exposed because these were “encrypted and/or hashed.”

“Therefore, the hacker was not able to access any customer environments or customer data,” the email concluded.

But if the “two obsolete servers” weren’t part of the OCI system, what were they part of? And what, if any, customer data did the hacker access? At this point, the opinions of security researchers and the counter-assertions by Oracle, start to diverge.

The fact that a breach of some kind had occurred was first made public in March, when a hacker using the moniker ‘rose87168’ publicized on a breach forum their theft of six million single sign on (SSO) and Lightweight Directory Access Protocol (LDAP) credentials, among other sensitive data, allegedly stolen from the Oracle Cloud platform.

If true, that would be a big deal; SSO and LDAP credentials, even if competently hashed, are not something any cloud provider or customer would want to be in the hands of a third party.

The hacker told Bleeping Computer that they gained access to the Oracle system in February, after which they had attempted (and failed) to extort payment from Oracle in return for not releasing the data.

But even if the hashes remained secure, other sensitive data could be used to mount targeted attacks, noted security company Trustwave:

“The dataset includes PII, such as first and last names, full display names, email addresses, job titles, department numbers, telephone numbers, mobile numbers, and even home contact details,” wrote Trustwave’s researchers, pointing out that the consequences of such a breach could be expensive.

“For the organizations affected, a leak like this one could result in data breach liabilities, regulatory penalties, reputational damage, operational disruption, and long-term erosion of client trust,” they wrote.

Oracle subsequently denied the breach claim, telling the media: “The published credentials are not for the Oracle Cloud. No Oracle Cloud customers experienced a breach or lost any data.”

In early April, the company changed tack slightly, admitting that it had been breached, but insisting that the data had been taken from a “legacy environment” (aka Oracle Classic) dating back to 2017. That story claimed that Oracle had started contacting customers, mentioning that the FBI and CrowdStrike were investigating the incident.

This incident was in addition to a separate data breach – described as a “cybersecurity event” – affecting Oracle’s healthcare subsidiary, Oracle Health.

So far so good regarding Oracle’s denials, except that the hacker subsequently shared data showing their access to login.us2.oraclecloud.com, a service that is part of the Oracle Access Manager, the company’s IAM system used to control access to Oracle-hosted systems.

It also emerged that some of the leaked data appeared to be from 2024 or 2025, casting doubt on Oracle’s claim that it was old.

So, was Oracle’s main OCI platform breached or not? Not everyone is convinced by the company’s flat denials. According to prominent security researcher Kevin Beaumont, the company was basically “wordsmithing” the difference between the Oracle Classic servers it admits were breached, and OCI servers, which it still maintains were not.

“Oracle rebadged old Oracle Cloud services to be Oracle Classic. Oracle Classic has the security incident,” noted Beaumont in a dissection of the incident and Oracle’s response on Medium.

“Oracle are denying it’s on ‘Oracle Cloud’ by using this scope – but it’s still Oracle cloud services, that Oracle manage. That’s part of the wordplay.” Oracle had also quietly contacted multiple customers to confirm some kind of breach, he said.

This leaves interested parties with the unsatisfactory sense that something untoward has happened, without it being clear what.

For now, Oracle is sticking to its guns that its main OCI platform is not involved, but perhaps the confusion could have been avoided with better communication.

Suffering a breach is hugely challenging for any organization but it sometimes pales beside the problems of communicating with customers, journalists, and the army of interested researchers ready to pick apart every ambiguity. Weeks on from the breach becoming public, those ambiguities have yet to be fully cleared up.