Belgium's finance and tax agency has pulled "several" digital services offline after a cyberattack on the organization. FOD Financiën confirmed the attack on Wednesday, saying that MyMinfin, the agency's main online tax portal, as well as other online services, are temporarily unavailable while they start the initial investigations. "This measure helps limit the risks and makes it possible to carry out the necessary technical interventions to ensure the security of our systems," it said in a public announcement. FOD Financiën added that "this has consequences for tax deadlines in the near future," referring to the October 31 extended deadline to submit tax filings for specific types of income, such as sole traders and earnings from foreign companies. The agency confirmed the deadline will be extended to November 16, by which time MyMinfin, the platform through which such filings would normally be submitted, should be back up and running. The detail offered up in the public statement reflects the early stage of the investigation; not much is known, although there is nothing to suggest data was compromised. "Data protection is a top priority for the FOD Financiën," it said. "At present, there are no indications that a data breach has occurred or that data has been compromised. This aspect is also being closely investigated and followed up. "In the meantime, a large part of our other applications remains available with full or partial functionality. We are closely monitoring the situation and doing everything we can to make the affected services available again as soon as possible." Spokesperson Francis Adyns told local news outlets that the attack was thwarted within hours, and that it was unable to gain access to applications or data. "The attack could not be sufficiently expanded within our environment to take over applications or gain access to data," he told Nieuwsblad. "Elements that were potentially infected were isolated. As a result, MyMinfin, Tax-on-web, and Biztax went offline, but the hacking was successfully stopped. "The various services must be restored in an isolated environment. This requires considerable time to realize, with the necessary caution to rule out new risks." ®

The UK’s comms watchdog has put forward four methods of checking netizens aren't kids – dubbed highly effective age assurance (HEAA) – as it prepares for the proposed under-16 social media ban. The regulator says some adults may not need to prove their over-16-ness to social media platforms that will make inferences about their age based on previous activity, but confirmed that "many" are likely to have to undergo the same verification process. Big Brother Watch's (BBW) Director Silkie Carlo said: "This plan for a government 'social media ban' is a national ID system by the back door. Both the government and Ofcom have admitted that children will get around the ban, which means the real effect will be normalizing adults and children alike to handing over their passports just to get online." Ofcom says four methods remain from the seven it initially outlined when the Online Safety Act (OSA) came into force last year. The seven were capable of verifying whether a subject was 18 years old, but there are fewer viable options for determining the age of 16-year-olds, it said today. The methods put forward include: Photo-ID matching: Checking information displayed on identity documents and analyzing the photo against a live image of the subject taken during the verification process Banking checks: An estimated 90 percent of 16-17-year-olds in the UK have a bank account, which they would have provided their identity documents to open. The information processed by the bank can be used to verify whether someone is aged 16 or older Digital ID services: An interesting entry, given how quickly these were circumvented once the OSA age-checking requirements came into force. These third-party services analyze a person’s photo once, and if it matches the age they claim to be, let them verify their age across other services Facial age estimation: A method that even Ofcom admitted isn’t quite reliable enough to be used on its own. The regulator said that online services can use technologies to analyze a subject’s facial features to determine their age. The same technologies also have a margin of error of a few years, so online services may wish to use a second method of HEAA to verify the results of this check. The three reserved for those aged 18 and above include credit card checks (only adults can have a credit card), mobile network checks (MNOs require proof of adulthood to remove content blocks), and email checks – using a subject’s email address to make educated guesses about their age based on the other types of services with which it is registered. Ofcom acknowledged that not every 16-year-old will have a form of photo ID, which is required for all four of its HEAA methods, so they will need to acquire one in order to access online services. It estimates that around 94 percent of 16-17-year-olds in the UK have a form of photo ID, such as a passport, driving licence, or an ID card certified by the Proof of Age Standards Scheme, and that around 150,000 have neither. BBW's Carlo added: "Hundreds of thousands of people without ID, who tend to be poorer people, and many more who don’t want to risk handing their passports over to foreign tech companies will be locked out of huge parts of the internet. "The plan will kill anonymity online, whilst the UK’s culture of speech policing is reaching a crisis point. The policy is painfully misguided, an Orwellian assault on free speech and privacy, and will make children no safer at all." 'Circumvention inevitable' Ofcom admitted that "the risk of circumvention cannot be entirely eliminated," as some children will find ways to bypass these age checks, no matter how fully they are implemented. It cited Australia sporadically in its announcement, a country that introduced an under-16 social media ban in December 2025, but has struggled with a large proportion of children devising ways to circumvent these checks. Ofcom said the UK government intends to adopt, but learn lessons from, Australia’s rollout, committing to implementing more robust measures that promote the ban’s aims. It said it has identified some mitigations that could be taken to counter circumvention, such as making it easier for users to report suspected underage social media users, and “using age inference models.” The regulator said it will closely monitor circumvention for the first 12 months after the ban is enforced to understand possible methods to prevent children from finding ways around the age checks. In May, nearly a year after the OSA’s age verification requirements kicked in, researchers found that the existing age checks proved largely ineffective at keeping under-18s away from adult content online. Some reported beating age checks with just a drawn-on moustache. England's Children's Commissioner, Dame Rachel de Souza, said recently that the OSA "has made absolutely no difference" to children’s ability to access potentially harmful online content. Commenting on today’s announcement, Ofcom chief exec Dame Melanie Dawes said that when the social media ban takes effect, it will take a whole-of-society approach to ensure the ban is upheld. ?This ban will shape the future of children’s lives online, so it’s important to get it right," she said. "It can work if social media firms do highly effective age checks properly, and we’ve set out ways that could be achieved. When it comes into force next year, we’ll be ready to take swift and firm action against any company that fails to comply. "We should expect that motivated children will seek to bypass the restrictions – just like alcohol laws can’t completely eradicate underage drinking – but there’ll be ways for platforms to mitigate this risk. This will be a huge cultural shift for our society, so it’ll take time to adjust, and everyone will have a part to play." The UK government is expected to outline the first set of regulations related to the under-16 social media ban by the end of the year, and Ofcom is in the process of developing draft guidance for platforms. ®

EXCLUSIVE Researchers identified at least 83 attacks against 61 public GitHub repositories, including popular open source projects such as Google LangExtract, Trivy, Brave browser, and MLflow, in what they suspect is a coordinated campaign to execute commands in CI/CD environments and steal credentials and access tokens. It all happened very quickly, the Radware threat hunters said in an exclusive interview with The Register. Most (77) of the malicious items were published during a 43-minute time span on September 1, with the remaining six occurring within the next two minutes. “Our guess is that the final aim was a supply-chain attack in which the attacker gains credentials for the repo, and then he has the power to change the contents – the code – as he wishes” and then push the malicious changes to others, Radware VP and researcher Gabi Nakibly told The Register. Nakibly and fellow Radware researcher Zvika Babo say they suspect a single individual is behind this supply chain campaign. This attacker used 74 different GitHub accounts, many of which had legitimate development histories, meaning they were likely compromised. "Considering that dozens of accounts posted the same type of payload, on the same day, within a narrow time window, and to the same infrastructure, it is reasonable to assess that the activity was coordinated,” the team wrote in research shared ahead of publication with The Register. A novel attack chain They discovered the campaign while investigating prompt injection in GitHub – and they told us the attack chain is part of what makes this supply-chain campaign novel, and extremely stealthy. First, the attacker publishes an issue, pull request, or comment containing malicious commands hidden in HTML comments. This ensures the content is not visible in the rendered page. Plus, a GitHub event – like a pull request or issue – can automatically trigger a workflow if the repository is configured to respond to that event, meaning the attacker can be pretty hands-off at this point. “The workflow automatically is triggered within a second, and if the workflow is indeed vulnerable, then the attack is executed successfully,” Nakibly said. The workflow incorporates attacker-controlled content directly into shell source code, and the shell executes the hidden, malicious command, which hoovers up environment variables and attempts to exfiltrate those to an attacker-controlled server. While the researchers examined logs from actual runs, and told us they found two cases containing evidence that the malicious command ran inside the automation environment, they can’t definitively say whether the attacker successfully obtained repository write permissions, modified source code, or compromised downstream software. But they're trying. “The big picture is that the attackers are trying to find every possible way to get inside the repos to get credentials,” Nakibly said. Plus, “the attacker doesn't need to compromise the repository or to have access to its codebase” to do this, Babo added. “Basically, every user with a GitHub account can try to run this attack – it's very easy to start this attack.” Which repos were affected? As of October 13, the threat hunters identified 83 GitHub items with a verified payload across 61 different repositories. The repos span AI frameworks, security tools, development infrastructure, databases, and other widely used open source software projects. The Radware report lists agno-agi/agno (42.7K stars), ToolJet/ToolJet (41.1K), google/langextract (38.9K), aquasecurity/trivy (38.4K), CopilotKit/CopilotKit (38K), and podman-container-tools/podman (33K), among the most popular. Other notable targets included QwenLM/qwen-code (28.5K), mlflow/mlflow (28.4K), discordjs/discord.js (26.8K), cilium/cilium (25.6K), brave/brave-browser (23.9K), dotnet/maui (23.3K), Homebrew/homebrew-cask (22.2K), github/docs (21K), apache/doris (16K), and PX4/PX4-Autopilot (12.8K). “These projects are used by thousands of organizations," Babo said. The researchers disclosed their findings to all of the projects’ maintainers, and most of the repositories were closed or fixed, but they can’t confirm that all of them were. This campaign follows several earlier supply chain attacks against open source security and dev tools as attackers increasingly look for new methods to steal credentials and other secrets. “There is no way to stop the attackers from attempting,” Nakibly said. “The only way is to make sure that the workflow code is resilient, and not vulnerable to such attacks." The researchers recommend applying least-privilege access to CI/CD workflows, and separating as much as possible workflows triggered by external events from jobs with elevated permissions. “Developers should treat external content as untrusted, and also limit the secrets and environment variables that are available to the workflow,” Babo said. ®

Welcome back to PWNED, in which The Reg offers cautionary tales from folks who’ve left their doors wide open to attackers and lived to tell the tale. This week’s misadventure involves unpatched older machines and a password that was supposed to send a message to crims. Our story comes courtesy once again of leading red teamer and pen tester Dahvid Schloss of Suzu Labs. A client asked Schloss to visit a factory and check the servers there for security holes. The company had been hacked six months prior, made some adjustments, and wanted to make sure that they were bulletproof now. Schloss' mission, which he chose to accept, was to get domain admin rights. Schloss drove over to the factory where he noticed a number of Windows 7 servers were connected to the CNC milling machines, even though Windows 10 was by then Microsoft's supported desktop OS. This was to be expected, as companies with proprietary software often use legacy OSes for fear of breaking apps. At first, Schloss had a hard time breaking in because most of the servers were not connected to the domain. So there was no point in his running the EternalBlue zero-day that would have let him in. “So I've been looking through these and most of them had been disconnected from the domain, so it's the right move,” he said. “Like, yeah, you could run EternalBlue on the network, but you really weren't going to be able to get anywhere with it, cuz you get on the device and what you find: you dump LSASS [the Windows Local Security Authority Subsystem Service], you’re like ‘All right, there’s local admin creds, but the local admin creds on those devices were different from the local admin creds on the majority of workstations.” Finally, Schloss went onto one of the servers that was connected to milling machines and found that it was connected to the network and on the domain. It was vulnerable to EternalBlue and he went and dumped LSASS and found a pair of creds from WDigest, one of which looked like an admin account. But Schloss thought that it must not be a legitimate admin account when he read the password : “heyhackergof***yourself,” but written in leet speak [l337 5p34k]. The resulting string was a strong password, but Schloss assumed that the admins were playing a game with him and left this credential there for him to find. Schloss assumed it wouldn't work and sat on it for a week. During a briefing he had with the IT crew, he presented his findings and then asked who set up the admin account with this funny password. “You could see everyone kind of looking at the senior manager of IT like ‘that was you, wasn’t it,’” Schloss explained. “He’s kind of got this face. I’m like ‘oh shit, like what?’ Turns out that ‘heyhackergof***yourself’ was the actual password for his admin account." On Monday, Schloss tried the username and password combo and, lo and behold, it gave him complete control of the entire network. He was then able to get access to other passwords and many of them were also insults directed at potential hackers. Schloss understood that the team was still angry about a breach they had suffered six months prior and, should they be breached again, wanted to give the finger to the hacker who did it. Unfortunately, their system was still vulnerable because of the outdated machine that was hooked up to the domain and he was able to gain control. The lesson here is really to patch your systems and avoid using insecure legacy OSes whenever possible, because it was an old machine that let Schloss in, not a weak password. Indeed, “hackergof***yourself” in leet speak isn’t a terrible password, just an embarrassing one if it's exposed. ®

Attackers are probing a critical Oracle E-Business Suite vulnerability that can lead to remote code execution (RCE), despite Oracle issuing a patch earlier this month. Meanwhile, new analysis indicates that an Oracle PeopleSoft zero-day exploited by ShinyHunters as early as May involves three distinct vulnerabilities that can be combined to achieve RCE. Patching alone may not remove attackers from already compromised systems, particularly if they've installed web shells. First up: CVE-2026-101767, a critical, unauthenticated SQL injection bug in Oracle EBS that can lead to RCE. “Our Oracle E-Business Suite decoys recorded exploratory exploits against CVE-2026-101767, an unauthenticated SQL injection in EBS's Thin Client Framework servlet that chains to remote code execution, this morning, Oct 27,” Defused Cyber said in an X post. Horizon3 researchers found and disclosed the bug to Oracle, and the vendor patched the issue in its October release. “An attacker can send a crafted request to the vulnerable servlet to execute SQL with the privileges of the APPS database user,” Horizon3 explained at the time. “The attack chain also enables operating system command execution with the privileges of the EBS application account.” This means an unauthorized user can modify application data accessible to APPS, and execute commands. “Depending on the deployment, affected data may include financial, payroll, HR, and procurement records,” the bug hunters said. The Register reached out to Oracle with multiple questions for this story - including whether it has documented any successful exploitation of CVE-2026-101767 - and did not receive an immediate response. Moving on to the PeopleSoft-ShinyHunters fiasco: TrendAI’s Zero Day Initiative (ZDI) found and reported the PeopleSoft issues on June 10, and Oracle issued a patch under one vulnerability identifier: CVE-2026-35273. In early June, ShinyHunters told The Reg that the group hacked more than 100 organizations via an Oracle PeopleSoft zero-day, CVE-2026-35273. Google’s consulting and incident response biz, Mandiant, later confirmed the data theft and extortion crew exploited CVE-2026-35273 as a zero-day, mostly against schools and the education sector. By late September, however, Mandiant said ShinyHunters massively expanded its targeting, “deploying web shells on dozens of systems globally, spanning higher education, technology, IT services, healthcare, agriculture, transportation, and government.” According to ZDI bug hunter Bobby Gould, there are actually three distinct vulnerabilities across multiple PeopleSoft components, and each should receive its own CVE identifier rather than being grouped under CVE-2026-35273. Gould, along with TrendAI researchers Minh Giang and Lucas Miller, originally found and reported three distinct bugs to Oracle in June. “We are coordinating with Oracle to assign separate CVEs for each issue,” he said in a Tuesday blog. The first issue is a Server-Side Request Forgery (SSRF) vulnerability in the PeopleSoft Integration Gateway (PSIGW), which gives attackers a foothold in the PeopleSoft application. In June, Oracle introduced a “validateClient” method to allow PeopleSoft system administrators to restrict access to certain functionality. The SSRF bug, however, allows crims to make requests that satisfy the validation requirement to access endpoints vulnerable to RCE, Gould wrote. “While this solution does restrict access, an attacker on any trusted host can still reach PSEMHUB,” he said, referring to PeopleSoft Environment Management Hub (PSEMHUB). “Because Oracle allows localhost by default, the PSIGW SSRF provides exactly that access.” The second bug is an external control of file path vulnerability in PSEMHUB’s ExecuteProcessActivityCommand handler. This message handler is designed to allow remote clients to write log entries to the PeopleSoft server’s filesystem - but it doesn’t properly validate requests, which allows an attacker to write a web shell into a file path and achieve RCE. The third vulnerability, also in PSEMHUB, is a deserialization of untrusted data flaw. An attacker can use a file-write vulnerability to plant a malicious XML file inside a PeopleSoft directory that stores environment configuration data, then wait for PSEMHUB to initialize, such as after a service or system restart. This triggers deserialization of the malicious XML file, potentially allowing the attacker to achieve RCE. “Attackers can combine these vulnerabilities to compromise affected instances of PeopleSoft,” Gould warned.®