The binary-parser library for Node.js contains a code injection vulnerability that may allow arbitrary JavaScript code execution if untrusted input is used to construct parser definitions. Versions prior to 2.3.0 are affected. The issue has been resolved by the developer in a public update.
binary-parser is a JavaScript library to facilitate writing "efficient binary parsers in a simple and declarative manner." binary-parser (versions < 2.3.0) dynamically generates JavaScript code at runtime using the Function constructor. Certain user-supplied values—specifically, parser field names and encoding parameters—are incorporated into this generated code without validation or sanitization.
If an application passes untrusted or externally supplied data into these parameters, the unsanitized values can alter the generated code, enabling execution of attacker-controlled JavaScript. Applications that use only static, hardcoded parser definitions are not affected.
The vendor has released a fix and clarified the library’s design limitations in version 2.3.0.
In affected applications that construct parser definitions using untrusted input, an attacker may be able to execute arbitrary JavaScript code with the privileges of the Node.js process. This could allow access to local data, manipulation of application logic, or execution of system commands depending on the deployment environment.
Users of the binary-parser library should upgrade to version 2.3.0 or later, where the vendor has implemented input validation and mitigations for unsafe code generation. Developers should avoid passing untrusted or user-controlled values into parser field names or encoding parameters.
Thanks to the reporter Maor Caplan for identifying the vulnerability and to Keichi Takahashi for implementing the fix. This document was written by Timur Snoke.
| CVE IDs: | CVE-2026-1245 |
| Date Public: | 2026-01-20 |
| Date First Published: | 2026-01-20 |
| Date Last Updated: | 2026-01-21 17:34 UTC |
| Document Revision: | 2 |
VoidLink, the newly spotted Linux malware that targets victims' clouds with 37 evil plugins, was generated "almost entirely by artificial intelligence" and likely developed by just one person, according to the research team that discovered the do-it-all implant.…
Earlier this month, Iran’s internet connectivity faced one of its most severe disruptions in recent years with a near-total shutdown from the global internet and major restrictions on mobile access.
EFF joined architects, operators, and stewards of the global internet infrastructure in calling upon authorities in Iran to immediately restore full and unfiltered internet access. We further call upon the international technical community to remain vigilant in monitoring connectivity and to support efforts that ensure the internet remains open, interoperable, and accessible to all.
This is not the first time the people in Iran have been forced to experience this, with the government suppressing internet access in the country for many years. In the past three years in particular, people of Iran have suffered repeated internet and social media blackouts following an activist movement that blossomed after the death of Mahsa Amini, a woman murdered in police custody for refusing to wear a hijab. The movement gained global attention and in response, the Iranian government rushed to control both the public narrative and organizing efforts by banning social media and sometimes cutting off internet access altogether.
EFF has long maintained that governments and occupying powers must not disrupt internet or telecommunication access. Cutting off telecommunications and internet access is a violation of basic human rights and a direct attack on people's ability to access information and communicate with one another.
Our joint statement continues:
“We assert the following principles:
Read the letter in full here.
The Open5GS WebUI component contains default hardcoded secrets used for security-sensitive operations, including JSON Web Token (JWT) signing. If these defaults are not changed, an attacker can forge valid authentication tokens and gain administrative access to the WebUI. This can result in unauthorized access to protected management endpoints.
Open5GS is an open-source implementation of 5G core network functions. It includes an optional WebUI component implemented using Node.js and Next.js for managing configuration and subscriber data. The WebUI relies on multiple secret values provided via Node.js process.env environment variables. These include secrets used for cryptographic operations such as signing and validating JSON Web Tokens (JWTs). By default, these environment variables are initialized to the static value change-me, including the JWT signing secret. JWTs are commonly used to implement authentication and authorization, as well as to securely transmit claims such as user roles and permissions.
In the Open5GS WebUI, these tokens are issued and validated using the default hardcoded secret unless explicitly overridden by the executing environment by the operator. The WebUI, on startup, does not emit warnings or enforce changes to these default secrets. As a result, deployments that do not manually override the defaults will operate with predictable and publicly known cryptographic keys. An attacker with network access to the WebUI can exploit this condition to forge valid administrative JWTs.
While the WebUI includes Cross-Site Request Forgery (CSRF) protections, these controls are ineffective against requests authenticated with valid forged JWTs. The WebUI is commonly deployed in containerized environments and may be assumed to be locally exposed; however, misconfigurations or local access assumptions can still place the interface at risk.
An unauthenticated network attacker with access to the WebUI component can generate forged JWTs using the known default secret. With these tokens, the attacker can access or modify protected REST endpoints under /api/db/*. This vulnerability allows unauthorized read and write access to sensitive data, including subscriber information and system configuration. CSRF protections do not mitigate this attack, as the forged tokens satisfy authentication requirements. Successful exploitation may result in full access of the WebUI component and all of its permissions.
A patch addressing this issue is available in the following pull request: https://github.com/open5gs/open5gs/pull/4279 against the version v2.7.6 released in July 2025. The patch introduces the use of a self-contained .env file for the WebUI’s Next.js environment and removes reliance on hardcoded default secret values. This ensures that each WebUI deployment generates and uses independent, locally scoped cryptographic secrets, reducing the risk of token forgery and key reuse across instances.
Developers integrating or redistributing the WebUI component are encouraged evaluate, validate and adopt the changes within their own environments prior to deployment
Users who are unable to apply the patch should manually configure their Node.js environment to define strong, cryptographically secure random values for the following environment variables:
- process.env.SECRET_KEY
- process.env.JWT_SECRET_KEY
These values preferable are unique per deployment and treated as sensitive secrets. Additionally, operators are advised to restrict access to the WebUI by placing it behind appropriate network controls, such as authentication gateways or secure content inspection proxies, to limit exposure from untrusted networks.
Thanks to the reporter Andrew Fasano from NIST's Center for AI Standards & Innovation. This document was written by Laurie Tyzenhaus. The software patch was written by Vijay Sarvepalli.
| CVE IDs: | CVE-2026-0622 |
| Date Public: | 2026-01-20 |
| Date First Published: | 2026-01-20 |
| Date Last Updated: | 2026-01-20 17:41 UTC |
| Document Revision: | 1 |
We've identified an aspect of Azure’s Private Endpoint architecture that could expose Azure resources to denial of service (DoS) attacks.
The post DNS OverDoS: Are Private Endpoints Too Private? appeared first on Unit 42.
No doubt, your organization has been hard at work over the past several years implementing industry best practices, including a Zero Trust architecture. But even so, the cybersecurity race only continues to intensify.
AI has quickly become a powerful tool misused by threat actors, who use it to slip into the tiniest crack in your defenses. They use AI to automate and launch password attacks and phishing attempts at scale, craft emails that seem to come from people you know, manufacture voicemails and videos that impersonate people, join calls, request IT support, and reset passwords. They even use AI to rewrite AI agents on the fly as they compromise and traverse your network.
To stay ahead in the coming year, we recommend four priorities for identity security leaders:
Enhance your security strategy: Deep dive into how to unify identity and network access through practical Zero Trust measures in our comprehensive four-part series.
2026 is the year to integrate AI agents into your workflows to reduce risk, accelerate decisions, and strengthen your defenses.
While security systems generate plenty of signals, the work of turning that data into clear next steps is still too manual and error-prone. Investigations, policy tuning, and response actions require stitching together an overwhelming volume of context from multiple tools, often under pressure. When cyberattackers are operating at the speed and scale of AI, human-only workflows constrain defenders.
That’s where generative AI and agentic AI come in. Instead of reacting to incidents after the fact, AI agents help your identity teams proactively design, refine, and govern access. Which policies should you create? How do you keep them current? Agents work alongside you to identify policy gaps, recommend smarter and more consistent controls, and continuously improve coverage without adding friction for your users. You can interact with these agents the same way you’d talk to a colleague. They can help you analyze sign-in patterns, existing policies, and identity posture to understand what policies you need, why they matter, and how to improve them.
In a recent study, identity admins using the Conditional Access Optimization Agent in Microsoft Entra completed Conditional Access tasks 43% faster and 48% more accurately across tested scenarios. These gains directly translate into a stronger identity security posture with fewer gaps for cyberattackers to exploit. Microsoft Entra also includes built-in AI agents for reasoning over users, apps, sign-ins, risks, and configurations in context. They can help you investigate anomalies, summarize risky behavior, review sign-in changes, remediate and investigate risks, and refine access policies.
The real advantage of AI-powered protection is speed, scale, and adaptability. Static, human-only workflows just can’t keep up with constantly evolving cyberattacks. Working side-by-side with AI agents, your teams can continuously assess posture, strengthen access controls, and respond to emerging risks before they turn into compromise.
Where to learn more: Get started with Microsoft Security Copilot agents in Microsoft Entra to help your team with everyday tasks and the complex scenarios that matter most.
Another critical shift is to make every AI agent a first-class identity and govern it with the same rigor as human identities. This means inventorying agents, assigning clear ownership, governing what they can access, and applying consistent security standards across all identities.
Just as unsanctioned software as a service (SaaS) apps once created shadow IT and data leakage risks, organizations now face agent sprawl—an exploding number of AI systems that can access data, call external services, and act autonomously. While you want your employees to get the most out of these powerful and convenient productivity tools, you also want to protect them from new risks.
Fortunately, the same Zero Trust principles that apply to human employees apply to AI agents, and now you can use the same tools to manage both. You can also add more advanced controls: monitoring agent interaction with external services, enforcing guardrails around internet access, and preventing sensitive data from flowing into unauthorized AI or SaaS applications.
With Microsoft Entra Agent ID, you can register and manage agents using familiar Entra experiences. Each agent receives its own identity, which improves visibility and auditability across your security stack. Requiring a human sponsor to govern an agent’s identity and lifecycle helps prevent orphaned agents and preserves accountability as agents and teams evolve. You can even automate lifecycle actions to onboard and retire agents. With Conditional Access policies, you can block risky agents and set guardrails for least privilege and just in time access to resources.
To govern how employees use agents and to prevent misuse, you can turn to Microsoft Entra Internet Access, included in Microsoft Entra Suite. It’s now a secure web and AI gateway that works with Microsoft Defender to help you discover use of unsanctioned private apps, shadow IT, generative AI, and SaaS apps. It also protects against prompt injection attacks and prevents data exfiltration by integrating network filtering with Microsoft Purview classification policies.
When you have observability into everything that traverses your network, you can embrace AI confidently while ensuring that agents operate safely, responsibly, and in line with organizational policy.
Where to learn more: Get started with Microsoft Entra Agent ID and Microsoft Entra Suite.
There’s often a gap between what your identity system can see and what’s happening on the network. That’s why our next recommendation is to unify the identity and network access layers of your Zero Trust architecture, so they can share signals and reinforce each other’s strengths through a unified policy engine. This gives you deeper visibility into and finer control over every user session.
Today, enterprise organizations juggle an average of five different identity solutions and four different network access solutions, usually from multiple vendors.1 Each solution enforces access differently with disconnected policies that limit visibility across identity and network layers. Cyberattackers are weaponizing AI to scale phishing campaigns and automate intrusions to exploit the seams between these siloed solutions, resulting in more breaches.2
An access security platform that integrates context from identity, network, and endpoints creates a dynamic safety net—an Access Fabric—that surrounds every digital interaction and helps keep organizational resources secure. An Access Fabric solution wraps every connection, session, and resource in consistent, intelligent access security, wherever work happens—in the cloud, on-premises, or at the edge. Because it reasons over context from identity, network, devices, agents, and other security tools, it determines access risk more accurately than an identity-only system. It continuously re‑evaluates trust across authentication and network layers, so it can enforce real‑time, risk‑based access decisions beyond first sign‑in.
Microsoft Entra delivers integrated access security across AI and SaaS apps, internet traffic, and private resources by bringing identity and network access controls together under a unified Zero Trust policy engine, Microsoft Entra Conditional Access. It continuously monitors user and network risk levels. If any of those risk levels change, it enforces policies that adapt in real time, so you can block access for users, apps, and even AI agents before they cause damage.
Your security teams can set policies in one central place and trust Entra to enforce them everywhere. The same adaptive controls protect human users, devices, and AI agents wherever they move, closing access security gaps while reducing the burden of managing multiple policies across multiple tools.
Where to learn more: Read our Access Fabric blog and learn more in our new four-part webinar series.
To address modern cyberthreats, you need to start from a secure baseline—anchored in phishing‑resistant credentials and strong identity proofing—so only the right person can access your environment at every step of authentication and recovery.
A baseline security model sets minimum guardrails for identity, access, hardening, and monitoring. These guardrails include must-have controls, like those in security defaults, Microsoft-managed Conditional Access policies, or Baseline Security Mode in Microsoft 365. This approach includes moving away from easily compromised credentials like passwords and adopting passkeys to balance security with a fast, familiar sign-in experience. Equally important is high‑assurance account recovery and onboarding that combines a government‑issued ID with a biometric match to ensure that no bad actors or AI impersonators gain access.
Microsoft Entra makes it easy to implement these best practices. You can require phishing‑resistant credentials for any account accessing your environment and tailor passkey policies based on risk and regulatory needs. For example, admins or users in highly regulated industries can be required to use device‑bound passkeys such as physical security keys or Microsoft Authenticator, while other worker groups can use synced passkeys for a simpler experience and easier recovery. At a minimum, protect all admin accounts with phishing‑resistant credentials included in Microsoft Entra ID. You can even require new employees to set up a passkey before they can access anything. With Microsoft Entra Verified ID, you can add a live‑person check and validate government‑issued ID for both onboarding and account recovery.
Combining access control policies with device compliance, threat detection, and identity protection will further fortify your foundation.
Where to learn more: Read our latest blog on passkeys and account recovery with Verified ID and learn how you can enable passkeys for your organization.
The plan for 2026 is straightforward: use AI to automate protection at speed and scale, protect the AI and agents your teams use to boost productivity, extend Zero Trust principles with an Access Fabric solution, and strengthen your identity security baseline. These measures will give your organization the resilience it needs to move fast without compromise. The threats will keep evolving—but you can tip the scales in your favor against increasingly sophisticated cyberattackers.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
1Secure employee access in the age of AI report, Microsoft.
2Microsoft Digital Defense Report 2025.
The post Four priorities for AI-powered identity and network access security in 2026 appeared first on Microsoft Security Blog.
A stack-based buffer overflow vulnerability exists in GNU libtasn1, a low-level ASN.1 parsing library. The issue is caused by unsafe string concatenation in the asn1_expand_octet_string function located in decoding.c. Under worst-case conditions, this results in a one-byte stack overflow that may corrupt adjacent memory. While the overflow is limited to a single byte, such conditions can still lead to unexpected behavior when processing untrusted ASN.1 input data.
GNU libtasn1 is a low-level C library for manipulating Abstract Syntax Notation One (ASN.1) data structures and encoding rules, including Distinguished Encoding Rules (DER). It implements functionality defined by ITU-T Recommendations X.680 and X.690 and is widely used as a foundational component in cryptographic software stacks to parse and validate complex ASN.1-encoded data.
A stack-based buffer overflow has been identified in the function asn1_expand_octet_string in the file decoding.c. The vulnerability arises from the use of unbounded string manipulation functions (strcpy and strcat) to construct a local stack buffer (name) using the fields definitions->name and p2->name. In the worst-case scenario, both source strings may be at their maximum allowed length. When concatenated together with an additional separator character (".") and a terminating null byte, the destination buffer is undersized by one byte. As a result, the final null terminator written by strcat overflows the allocated stack buffer by a single byte.
Although the overflow is limited in size, it occurs during the parsing of potentially untrusted ASN.1 input. One-byte stack overflows have historically led to subtle memory corruption issues and may cause unexpected behavior, including crashes, during cryptographic operations such as signature verification or certificate parsing.
An attacker could trigger the buffer overflow using a malformed ASN.1 data to potential corrupt memory or cause unexpected behavior. This requires breaking libtasn1’s assumption that ASN.1 structures passed to it are already validated by the main application using this library. The impact of this vulnerability is limited due to the one-byte nature of the overflow. Exploitation is constrained and may be further mitigated by modern compiler protections such as stack canaries, _FORTIFY_SOURCE, and other hardening mechanisms. However, as the GNU libtasn1 is commonly used in cryptographic libraries and security-sensitive contexts, malformed ASN.1 input triggering this condition could result in parsing failures or abnormal behavior during critical cryptographic operations, including signature verification and cryptographic data validation.
A patch addressing this issue has been proposed to the GNU libtasn1 project and is available for review and testing at: https://gitlab.com/gnutls/libtasn1/-/merge_requests/121. Developers and integrators are encouraged to evaluate the patch and apply appropriate mitigations, such as using bounded string operations or safer formatting functions, to eliminate the overflow condition in affected versions. Read https://gitlab.com/gnutls/libtasn1/-/blob/master/NEWS.md for updates
Thanks to Benny Zelster from Microsoft Research for coordinating the disclosure of this vulnerability.This document was written by Vijay Sarvepalli.
| CVE IDs: | CVE-2025-13151 |
| Date Public: | 2026-01-20 |
| Date First Published: | 2026-01-20 |
| Date Last Updated: | 2026-01-20 16:27 UTC |
| Document Revision: | 1 |
Researchers have found another method used in the spirit of ClickFix: CrashFix.
ClickFix campaigns use convincing lures—historically “Human Verification” screens—to trick the user into pasting a command from the clipboard. After fake Windows update screens, video tutorials for Mac users, and many other variants, attackers have now introduced a browser extension that crashes your browser on purpose.
Researchers found a rip-off of a well-known ad blocker and managed to get it into the official Chrome Web Store under the name “NexShield – Advanced Web Protection.” Strictly speaking, crashing the browser does provide some level of protection, but it’s not what users are typically looking for.
If users install the browser extension, it phones home to nexsnield[.]com (note the misspelling) to track installs, updates, and uninstalls. The extension uses Chrome’s built-in Alarms API (application programming interface) to wait 60 minutes before starting its malicious behavior. This delay makes it less likely that users will immediately connect the dots between the installation and the following crash.
After that pause, the extension starts a denial-of-service loop that repeatedly opens chrome.runtime port connections, exhausting the device’s resources until the browser becomes unresponsive and crashes.
After restarting the browser, users see a pop-up telling them the browser stopped abnormally—which is true but not unexpected— and offering instructions on how to prevent it from happening in the future.
It presents the user with the now classic instructions to open Win+R, press Ctrl+V, and hit Enter to “fix” the problem. This is the typical ClickFix behavior. The extension has already placed a malicious PowerShell or cmd command on the clipboard. By following the instructions, the user executes that malicious command and effetively infects their own computer.
Based on fingerprinting checks to see whether the device is domain-joined, there are currently two possible outcomes.
If the machine is joined to a domain, it is treated as a corporate device and infected with a Python remote access trojan (RAT) dubbed ModeloRAT. On non-domain-joined machines, the payload is currently unknown as the researchers received only a “TEST PAYLOAD!!!!” response. This could imply ongoing development or other fingerprinting which made the test machine unsuitable.
The extension was no longer available in the Chrome Web Store at the time of writing, but it will undoubtedly resurface with an other name. So here are a few tips to stay safe:
Pro tip: the free Malwarebytes Browser Guard extension is a very effective ad blocker and protects you from malicious websites. It also warns you when a website copies something to your clipboard and adds a small snippet to render any commands useless.
We don’t just report on threats—we remove them
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
Login