Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Latest News

U.S. Security Expert Sentenced for Aiding BlackCat Ransomware Gang

  A cybersecurity professional has become the third U.S. security expert sentenced to prison for aiding a ransomware gang, marking a signifi...

All the recent news you need to know
vulnerabilities and Exploits
binarly firmware IoT U-Boot vulnerabilities and Exploits

Six U-Boot Vulnerabilities Could Enable Pre-Boot Code Execution and Persistent Firmware Attacks

 



Security researchers have identified six vulnerabilities in the widely deployed U-Boot bootloader that could allow attackers to execute malicious code during the earliest stages of a device's startup process. If successfully exploited, the flaws could enable firmware-level attacks capable of bypassing security protections before the operating system loads and establishing malware designed to remain on affected systems.

As one of the most widely used open-source bootloaders, U-Boot plays a fundamental role in the startup sequence of embedded Linux devices by initializing hardware and loading the operating system. It is integrated into a broad range of technologies, including enterprise server Baseboard Management Controllers (BMCs), networking equipment, industrial control systems, Internet of Things (IoT) devices, and numerous other embedded appliances.

Because the bootloader executes before the operating system and endpoint security tools become active, vulnerabilities at this stage can have far-reaching consequences. An attacker who gains control during the boot process may be able to interfere with the system's trusted startup sequence before conventional security controls have an opportunity to detect or prevent malicious activity.

One of U-Boot's primary security mechanisms is Verified Boot, which uses cryptographic signatures to verify the authenticity of firmware and operating system images before they are executed. During startup, only images signed with a trusted cryptographic key are intended to be loaded, helping prevent unauthorized or modified firmware from running on the device.

In a technical report published this week, firmware security company Binarly disclosed six vulnerabilities affecting U-Boot's Flattened Image Tree (FIT) signature verification code. The FIT framework is responsible for validating firmware images during the boot process, making it a critical component of the platform's chain of trust.

According to Binarly, researchers examined the verification logic because of its importance in maintaining firmware integrity during startup. Their analysis uncovered six distinct vulnerabilities ranging from denial-of-service conditions that can interrupt the boot process to flaws capable of enabling arbitrary code execution while processing untrusted firmware images.

The researchers said two of the vulnerabilities could potentially allow arbitrary code execution during firmware verification, while the remaining four can be exploited to trigger crashes during the boot process. Since these weaknesses affect the validation of firmware before the operating system starts, a successful exploit could allow malicious instructions to execute before higher-level security mechanisms become operational.

The disclosed vulnerabilities include a flaw identified as BRLY-2026-037 that can cause U-Boot to crash when processing a specially crafted firmware image and, under certain conditions, may also permit arbitrary code execution. BRLY-2026-038 is a memory corruption vulnerability that could enable attackers to execute malicious code during firmware signature verification. BRLY-2026-039 involves an out-of-bounds read that may force U-Boot to access memory beyond the firmware image, resulting in a system crash. BRLY-2026-040 is a null pointer dereference vulnerability that allows crafted firmware images to terminate the bootloader unexpectedly. BRLY-2026-041 stems from insufficient validation of externally stored firmware data and can also be used to crash vulnerable systems. The sixth flaw, BRLY-2026-042, involves unbounded recursion that can exhaust available stack memory and prevent the bootloader from completing the startup process.

Binarly noted that much of the affected code has been present since U-Boot version 2013.07, meaning the vulnerabilities could impact more than 50 stable releases of the project. Because many hardware manufacturers maintain customized downstream versions of U-Boot within their own firmware, the potential exposure extends beyond the upstream project to a large number of commercial products deployed across multiple industries.

If the arbitrary code execution vulnerabilities are successfully exploited, attackers could gain execution during one of the earliest phases of system initialization. Operating at this level may allow threat actors to alter the boot sequence, disable firmware security mechanisms, deploy persistent firmware malware, or perform other privileged actions before the operating system begins loading.

Firmware-based attacks can also be considerably more difficult to identify than malware operating within the operating system. Since malicious activity occurs before the operating system initializes, traditional endpoint security software and many monitoring tools may have limited visibility into the compromise, allowing malicious modifications to remain undetected for extended periods.

Binarly also noted that exploitation does not necessarily require physical access to a device. Systems equipped with Baseboard Management Controllers that support remote firmware updates could become vulnerable if an attacker first compromises the management interface. In such cases, a specially crafted firmware image could be uploaded and processed during the update process, potentially triggering the identified vulnerabilities.

The researchers reported all six vulnerabilities to the U-Boot maintainers and submitted patches addressing each issue. Those fixes have since been accepted into the project's upstream codebase. However, because U-Boot is incorporated into firmware by individual hardware manufacturers, vendors must integrate the patches into their own firmware releases before updates become available to customers.

Organizations operating embedded systems should monitor firmware advisories issued by their hardware vendors and apply security updates as they become available. Restricting access to firmware management interfaces, securing remote administration services such as BMCs, and verifying firmware authenticity before deployment can further reduce exposure while patches are being distributed.

Devices that have reached end-of-life or no longer receive firmware updates may remain permanently vulnerable, underscoring the long-term security challenges posed by legacy embedded systems that continue operating long after vendor support has ended.

Read more »
Workplace Surveillance
Artificial Intelligence data security Employee Data Tracking Meta AI Model Capability Initiative Privacy Workplace Surveillance

Meta Faces Privacy Questions After Employee Data Exposure Report


 

After sensitive employee information was reportedly made available throughout the organization, Meta has suspended an internal employee monitoring initiative intended to assist in the development of artificial intelligence systems. 

Initially introduced in April, the Model Capability Initiative was intended to collect workplace activity data to assist Meta in improving its artificial intelligence models through the collection of work activity data. The system was reportedly used by employees to monitor interactions across various workplace applications including Gmail, Google Chat, and Meta’s AI assistant, as well as capture screenshots and usage patterns. 

In response to concerns about privacy and consent, the initiative quickly drew criticism from employees. More than 1,600 Meta employees, including engineers, researchers, and designers, have signed a petition advocating the discontinuation of this program. Prior to the latest incident, the monitoring initiative had already been under scrutiny. A Reuters report reported that the program collected more information than originally indicated and stored some of the data unencrypted, raising concerns among employees about privacy. 

In internal discussions, employees were also concerned that personal information, including tax and medical records accessed from work devices, could be disclosed, despite assurances that the data would be protected and used solely for legitimate business purposes. According to the petition, employees argued that responsible AI development should not be compromised by individual privacy concerns. 

A company's stated commitment to building trustworthy and responsible artificial intelligence systems is in conflict with the company's collection of workplace data without meaningful consent. Following reports that sensitive employee information had been accessed internally by employees, the controversy became more intense. 

According to information cited in media reports, the exposed data could have included private communications, AI prompts, transcriptions, as well as performance data. The incident has sparked an internal investigation, though there is no evidence of the information being improperly accessed or misused. Meta, according to Reuters, suspended the initiative after filing an internal security incident (SEV) in response to employee data being widely accessible within the organization. 

As indicated in internal documentation, this information included artificial intelligence prompts and transcriptions, private conversations, personnel records, and classifications of data sensitivity. This incident raised new concerns regarding the collection, storage, and protection of employee information. The Meta program has been suspended while the matter is being investigated. 

A company spokesperson confirmed the initiative was designed with privacy safeguards and stressed the absence of any indication of unauthorized access during the investigation. As of the time of the investigation, Meta had not announced when the initiative might resume, and executives of Meta indicated that it would remain halted while the investigation continued. As Meta stated, the Model Capability Initiative will be suspended gradually and might not reach all employees immediately. 

A source familiar with the matter told Reuters that the monitoring tool was still recording employee activity on Monday afternoon while the company attempted to disable it across all its systems. An additional clarification of the incident was provided by Meta Chief Technology Officer Andrew Bosworth in a later interview, in which he stated that the incident was not the result of an external security breach. Bosworth reported that employee information generated through the program initially could only be accessed by a small number of authorized employees, but was accidentally stored in an internal location incorrectly by a researcher. 

According to Meta, there was no evidence of malicious activity found, and the incident was an internal error that caused the company to suspend the initiative while investigating the matter. The development indicates growing tensions between rapid advancement of artificial intelligence and employee privacy rights. The majority of technology companies are exploring new sources of training data to enhance the performance of their models, as well as investing heavily in artificial intelligence. 

Despite increasing competition in the AI industry, Meta is expected to spend more than $135 billion on infrastructure in 2018. According to leaked audio from an internal Meta meeting, Mark Zuckerberg was in favor of using employee-generated data for AI training, asserting that highly skilled employees could serve as valuable examples for AI systems. It has been criticized by privacy advocates, however. 

Digital rights experts have argued that extensive workplace monitoring raises serious concerns about employee consent and transparency. According to the incident report, maintaining employee trust and protecting sensitive information are critical challenges that organizations should not overlook as they accelerate the development of artificial intelligence. 

A growing concern is how to strike a balance between rapid AI innovation and employee privacy and data security, as exemplified by the incident. As Meta continues its internal investigation, the outcome will likely influence how organizations approach AI training, workplace monitoring, and responsible data governance in the years to come.
Read more »
Technology
Aflac Japan KDDI Nidec Sapporo Holdings Technology

Hackers Target Industries in Japan, Attacks Share One Pattern


Four big Japan cyberattacks point to a common trend: threat actors are getting access via third-party infrastructure and subsidiaries, not from corporate headquarters. 

While the attacks impacted companies from varying industries such as telecommunications, manufacturing, insurance, and brewing, the breaches have one same characteristic.

Attacks share same patterns

Instead of directly disrupting corporate headquarters, hackers gained access via third-party infrastructure, subsidiaries, and overseas operations. 

The impacted organizations are Nidec, KDDI, Aflac Japan, and Sapporo Holdings. While the attacks involved different contexts, the incidents hint towards an increasing attack surface that expands well beyond a company’s primary network.

About KDDI incident 

KDDI, a telecommunications provider, reported illegal access to an email platform used by various Japanese internet service providers.

KDDI reported the incident surfaced from a bug in third-party software, revealing around 14.22 million email account records throughout six ISPs.

The attack shows how a single bug inside shared infrastructure can impact various organizations continuously.

Aflac Japan incident

On June 30, Aflac Japan revealed that between June 15 and June 25, hackers gained access to its Japanese operations. The company claims that some 4.38 million clients and agents were impacted, and a portion of the documents included bank account details used to pay insurance premiums.

According to the insurance, the incident only affected its company in Japan and had no bearing on its operations in the United States.

The alleged tactics are similar to social engineering strategies previously linked to Scattered Spider, even though the business has not linked the attack to any particular threat organization.

Sapporo Holdings and Nidec incident

Sapporo Holdings revealed possible illegal access involving two foreign subsidiaries, Canadian brewer Sleeman and Singapore-based Pokka. After identifying suspicious activity, the company shut down the impacted systems and started an investigation to find out if any data had been taken or accessed.

Nidec, a manufacturing company, has revealed that its Taiwanese subsidiary, Nidec Chaun Choung Technology, was the subject of a ransomware attack.

More than two gigabytes of firm data, including personnel, financial, procurement, manufacturing, legal, and IT information, were allegedly taken by the BlackField ransomware organization, which claimed responsibility for the attack. A $2 million ransom was allegedly demanded by the organization.

Read more »
Malicious Software
Crypto Wallet cyber attack Cyber Security GitHub malicious npm package Malicious Software

Injective Labs GitHub Compromise Distributes Malicious npm Package Targeting Crypto Wallet Keys

 

Cybersecurity researchers have detected a software supply chain attack in which threat actors compromised the Injective Labs SDK GitHub repository and utilized it to distribute a backdoored version of the npm package containing cryptocurrency wallet credentials stealing capabilities. Researchers at security company Socket have identified that the attackers distributed the malicious code in the @injectivelabs/sdk-ts version 1.20.21 after compromising the GitHub account of one of the trusted maintainers. 

The compromised package was published to the npm registry on July 8, 2026, and subsequently deprecated. Nevertheless, the distribution channel for the malicious artifacts remained available on GitHub at the time of publication. The attackers distributed the backdoored SDK to 17 other @injectivelabs packages, including the wallet, utility, networking, and crypto modules. Since the packages include various apps as dependencies, developers who did not directly install the SDK might also be affected. 

Unlike traditional supply chain malware that typically persists in the compromised software at installation time, the detected backdoor was not activated when the developers installed the package. Rather, the malicious code was designed to exfiltrate the cryptographic assets when the developers used the SDK’s wallet generation feature. 

Thus, the threat actors could hide the malicious payload’s presence by avoiding the use of suspicious scripts typically associated with malware. The detected malware consisted of modified cryptographic functions that replaced the legitimate implementation with the backdoor, which the attackers masked as a performance telemetry component. The additional function exfiltrated the cryptographic assets, including the mnemonic seed phrase and private key generation details, required to recreate the cryptocurrency wallet. 

Researchers noted that the malware persisted in the compromised repositories by sending the collected data to the remote server in aggregated fashion to avoid suspicion by grouping multiple exfiltration requests into one encrypted HTTPS session. The security analysts at OX Security stated that the detected threat was capable of intercepting the master recovery phrase used to seed cryptocurrency wallets. Since the mnemonic seed phrase gives the adversary full access to the wallet funds, threat actors could reproduce the cryptographic assets to gain unauthorized access to the blockchain assets. 

The malware’s distribution channel was compromised using the trusted publishing infrastructure and OpenID Connect (OIDC) publishing pipeline. The detected threat utilized the legitimate account of one of the maintainers, which implies that the attackers did not have to use supply chain malware or impersonate the project on a third-party registry. The developers who installed the affected package should switch to the latest version, 1.20.23, which has been released. 

The security analysts advise the developers to consider all private keys and mnemonic phrases generated with the compromised version of the code as compromised and take the appropriate actions to rotate the cryptographic assets. Moreover, the developers should review their project dependencies to ensure that they do not use the affected versions of the packages indirectly. 

The incident demonstrated how the threat actors could target the software supply chain to compromise the cryptocurrency ecosystem and gain unauthorized access to the crypto assets by compromising the open-source developer infrastructure.
Read more »
Software Supply Chain
Cryptocurrency Wallet Security Cyber Security DeFi Security GitHub Compromise Injective SDK Mnemonic Seed Phrase NPM Supply Chain Attack Private Key Theft Software Supply Chain

Injective SDK Supply Chain Attack Exposed Developers to Cryptocurrency Wallet Theft


 

InjectiveLabs/SDK-TS, a widely used package, was briefly published on Node Package Manager (npm) as a malicious version after attackers gained access to a legitimate contributor's GitHub account, exposing developers to the theft of cryptocurrency wallet credentials. Several security researchers from Socket, Ox Security, and StepSecurity identified the supply chain attack as targeting Injective Labs' TypeScript/JavaScript SDK, which is used to develop applications based on Injective's blockchain.

The SDK is widely adopted by developers who create cryptocurrency wallets, decentralized finance (DeFi) applications, decentralized exchanges, trading bots, and payment platforms, with approximately 50,000 downloads per week on NPM. 

A significant security issue is the responsibility of the SDK when it comes to creating and importing cryptocurrency wallets, as it occupies a critical position in the development process. Developers and end users alike are particularly vulnerable to any compromise of the SDK because the wallet creation functions are crucial to the handling of users' mnemonic recovery phrases and private keys. 

Researchers have determined that hackers gained access to a legitimate contributor's GitHub account on June 8 and introduced malicious code, which was later released as version 1.20.21 for the @injectivelabs/sdk-ts package. Additionally, 17 additional Injective-related packages were referenced by the compromised release, resulting in a significant impact on downstream projects. According to security researchers, attackers compromised a legitimate maintainer's account after exploiting the trust-worthy GitHub publishing workflow of the project. 

As opposed to stealing an NPM publishing token or creating a fake package, the malicious version was distributed through the repository's normal release process, making the compromise appear genuine. Package maintainers detected the malicious activity within minutes, reverting the unauthorized changes and releasing a version that is free of malicious activity, 1.20.23. 

Nevertheless, systems that downloaded or updated the compromised package during the brief exposure window may still have been affected. In contrast to conventional malware that is executed during installation, the injected code is activated when developers create or import cryptocurrency wallets using SDK functions. 

When this was achieved, the malware captured private wallet keys and mnemonic seed sentences, encoded the information, and sent it via HTTP POST request to what appeared to be an official Injective Labs infrastructure endpoint in order to blend into normal network traffic. As a method of minimizing detection, the malware disguised its outbound communication as legitimate injective network traffic in order to prevent detection. 

By capturing multiple wallet secrets temporarily, encoding them, and transmitting them as a single request, the malicious activity was able to blend in with blockchain-related communications, avoiding detection. The malware, according to StepSecurity researchers, collected wallet secrets for approximately two seconds before bundling them into a single request to minimize suspicion while maximizing the amount of data stolen. 

In a recent report, Socket reported that 310 malicious packages had been downloaded before they were deprecated, but there is reportedly still availability of the associated malicious GitHub release artifacts. As a consequence of Ox Security's warning, the compromised SDK is dependent on 87 direct NPM packages, accounting for more than 112,000 cumulative downloads, illustrating the risk to a larger supply chain.

Researchers noted that even though the malicious payload was contained within @injectivelabs/sdk-ts, the compromised release affected 17 additional injective packages that depended on the infected SDK version. This could have resulted in developers installing the backdoored package unknowingly through normal project dependencies, thereby significantly expanding the attack's impact. 

It is advised that developers who suspect they may have installed the affected version transfer cryptocurrency assets immediately into new wallets, replace compromised private keys and seed phrases, and rotate any sensitive credentials stored within their development environment immediately. The incident underlines the growing threat posed by software supply chain attacks, particularly within the cryptocurrency ecosystem where a compromised development dependency may result in a significant financial loss to both developers and end users.

Due to the increasing sophistication of software supply chain attacks, organizations and developers must strengthen dependency verification, monitor package integrity, and respond quickly to compromised components so that credential theft and downstream compromise can be reduced.


Read more »
Cyber Security
Cryptographic Cryptographic Attacks Cryptographically Relevant Quantum Computer cryptography risk Cyber Security

QIZ Security Raises $17 Million to Expand Cryptographic Security and Post-Quantum Readiness Platform

 

Israeli cybersecurity startup QIZ Security has raised $17 million in seed funding to fuel the development of its cryptographic security management solution and post-quantum cryptographic (PQC) readiness platform. The Israeli cybersecurity company has seen rising demand for its service, which assists firms in inventorying their cryptography assets in preparation for the transition to post-quantum cryptography algorithms. 

The round was led by Bessemer Venture Partners and Merlin Ventures, with Evolution Equity Partners, Qbeat Ventures, Singtel Innov8, and Qino Cyber Capital also participating. The funding will support the company’s expansion and product development, with the company’s QIZ Security cryptographic governance platform’s research and development being the main focus. 

The startup was founded in 2022 by Ben Volkow, Lenny Ridel, and Itan Barmes, and its cybersecurity solution allows organizations to manage and inventory all cryptographic assets in on-premises, cloud, and hybrid environments without the need to scan their networks. Using industry standard APIs, QIZ Security’s cryptographic governance platform enables enterprises to detect and assess the risk of all certificates, encryption assets, security controls, protocols, cipher suites, and cryptographic keys. 

These details are automatically correlated to the organization’s applications and business processes discovered across hybrid cloud infrastructure environments. Moreover, the application detects vulnerabilities, weaknesses, and exposures to outdated encryption technologies that put enterprise data at risk in both transit and at rest. 

In addition, the company’s solution helps enterprises prioritize risks according to their technical and business significance and guides enterprises in responding to each identified risk. This empowers security operations and compliance teams to coordinate and accelerate activities and responses to cryptographic risks, ensuring that application owners and security stakeholders reduce exposure to business-specific threats. 

Modern cryptographic infrastructure governance is necessary for enterprises to inventory and better understand their cryptography assets, identify risks, and respond to them in a timely and cost-effective manner. With the upcoming quantum computing era, enterprises and government agencies are preparing to migrate their cryptographic infrastructure to post-quantum algorithms. This migration requires organizations to fully understand where their cryptography is, which encryption technologies put them at risk, and how best to respond. 

According to Chief Executive Officer Ben Volkow, enterprises are unable to effectively plan their transition to modern cryptography without gaining continuous visibility into their cryptography assets. Organizations need to take a step back and understand the overall state of cryptography in their IT environments to be prepared for upcoming changes. With the quantum era of computing arriving, businesses need to ensure they are taking the right steps now to safeguard their sensitive data. 

The news comes as governments and enterprises worldwide are beginning to acknowledge the need to inventory cryptographic assets to develop migration plans for post-quantum cryptography algorithms. Additionally, with increased concerns over the implications of quantum computing, multiple cybersecurity startups are positioning their services to assist enterprises in preparing their cryptography infrastructure for the transition to post-quantum cryptography algorithms.
Read more »
Subscribe to: Posts (Atom)

Featured