Docker + ActiveState Extending Secure Defaults to the Packages Developers Install

Trusted content is the foundation security-conscious organizations expect all builds to start from. Docker has made that possible for everyone by providing the foundation free. Docker Hardened Images (DHI) are open source under Apache 2.0, with a catalog of 4,000+ minimal images (and growing) built from source and continuously maintained by Docker. The catalog also carries customizable Helm charts and over 65,000 hardened system packages. For most services, adopting DHI is as simple as changing the FROM line.

Teams building on a secure foundation now want the same assurance for the open source their applications install. That open source is a different layer of the supply chain, where thousands of upstream projects are pulled in at build time by pip, npm and Maven, and by coding agents as well.

Docker is committed to one standard for trusted content across everything teams build on. A new partnership with ActiveState, the company that has been securing open source since 1997, extends that standard to the packages themselves. Together, we give teams the same assurance on both layers, from the hardened images Docker maintains to the packages developers and their agents install on them. Once configured, the integration allows developers and AI coding assistants to continue using familiar package managers and development workflows, while approved dependencies are sourced through governed repositories rather than directly from public registries.

A hardened foundation removes a class of security work before code is written

Most applications still start from a large, generic base image, and the cost of that choice keeps growing. A large image increases the attack surface and accumulates stale dependencies, and the CVEs it generates land on developers long after the image was chosen. By removing unnecessary packages, rebuilding components from source and continuously maintaining the image, Docker Hardened Images reduce the vulnerabilities inherited from the container foundation. Images can achieve near-zero known CVEs, which means less remediation work and less scanner noise before application code is introduced. The hardening and patching are handled once in the foundation, for every service that builds on it.

Key takeaways

• When the TeamPCP campaign weaponized a widely trusted security scanner in March, Docker Hardened Images were not affected. DHI’s controlled build pipeline and dependency cooldown periods helped prevent compromised upstream artifacts from entering the image build process during the attack window.

Without trusted content on both layers, your team inherits the risk

Above the base image sit the dependencies an application brings with it. DHI secures the operating system packages and the language runtime that ship in the image. The application’s own libraries are pulled in at build time by its package managers from public registries, where trust is assumed and seldom verified. That layer needs what the image now has, a source that admits only the versions a team has approved and stands behind the fix when one of them needs it. Coding agents now pull those packages too. As Mark Lechner, CISO wrote in April, a compromised dependency pulled by an agent has the same blast radius as a compromised developer machine.

This year’s supply chain incidents have followed one pattern. As Lechner documented, attackers steal developer credentials, use them to poison trusted packages, and the compromised packages steal more credentials. The axios compromise earlier this year put two backdoored versions of a library downloaded 83 million times a week into circulation for about three hours. Most of these attacks burn out within hours. A build that resolves fresh from a public registry, with no lockfile or cooldown in front of it, has nothing between it and a version published an hour ago. The slower failure is the vulnerability that surfaces in one of those libraries months later, when no one outside the team is accountable for the fix. Either way, without trusted content on both layers, the risk lands on your team.

One standard for trusted content, from the image to the packages built on it

Docker Hardened Images are the foundation, and Docker stands behind them. Each image ships with a signed SBOM and SLSA Build Level 3 provenance, with full, unsuppressed CVE visibility. A security team can see what is in the image and how it was built. For teams that need remediation on a predictable clock, DHI adds a 7-day SLA on critical and high CVEs, FIPS and STIG variants, and secure customization on its paid tiers.

While DHI secures the image, ActiveState hardens the open source built on it. ActiveState provides the Curated Catalog, a private, policy-governed repository of open source components that security teams curate and developers and AI coding assistants consume safely. The catalog holds only the packages a team has approved. ActiveState compiles every component from original source code in a SLSA Level 3 environment with full provenance and complete SBOMs, in place of pre-compiled binaries from a public registry. When a fix becomes available upstream, ActiveState rebuilds the component and publishes it to the catalog automatically under SLAs of 5 business days for critical CVEs and 10 for highs.

With DHI and the Curated Catalog together, both layers carry provenance, SBOMs and a remediation SLA from the hardened image to the packages built on it. That gives security teams a consistent evidence trail across the software supply chain. The artifact repository teams already run, Artifactory or Nexus, points at the Curated Catalog as its upstream the way it points at PyPI today. Developers keep the same pip and npm workflow, and coding agents are served the governed version. None of this replaces the pinned digests, cooldown periods and sandboxed agents Lechner recommends. It gives those controls a governed source to point at.

The agentic era demands trusted content at every layer

AI coding agents are changing how quickly organizations create software. They can generate applications, select dependencies and initiate builds at a pace that traditional security review processes were never designed to support. Still, faster development should not mean blindly accepting more supply chain risk. Docker Hardened Images reduce the security burden of maintaining container foundations. ActiveState’s Curated Catalog extends governance and managed vulnerability remediation to the open source libraries those applications depend on. The result is a more consistent approach to software supply chain security, with trusted foundations, governed dependencies, verifiable build evidence and clear remediation responsibilities.

The goal is not to add another security checkpoint that causes friction in your build process. It is to make the secure path the easiest path for developers, platform teams and AI coding agents alike.

Security scales when the defaults are strong and the foundation is maintained by a team accountable for it. In an increasingly agent-driven development environment, the security of what gets built depends heavily on the trustworthiness of what those agents are allowed to consume. Docker now resells the ActiveState Curated Catalog alongside DHI, and ActiveState resells DHI to its customers. The hardened image and the packages built on it are both available through Docker.

from Docker https://ift.tt/cA4KzWh
via IFTTT

ThreatsDay: Apache OFBiz RCE, DreamHost Breach, DeFi Site Hijacks + 17 More Stories

How much damage can someone do without breaking much? Quite a lot, it seems. A stolen login can open doors across several systems. A trusted setting can be used to lock people out. Even a simple file copy can reach places it shouldn't. And while new tools are helping find security holes faster, some important systems are still taking months, sometimes over a year, to get patched. Not exactly a great match.

The stranger part is how little some attacks now need. Ransom demands without encrypted files. Fake websites that look real enough to steal money. AI tools picking up dangerous instructions while trying to help. Even the attackers are making mistakes in their own code.

This week's stories are a reminder that the biggest problems don't always come from clever tricks. Sometimes the easy way works just fine. Here's what else happened.

The threats change every week. Subscribe, and we’ll alert you when each new ThreatsDay Bulletin is out.

1. AI Accelerates Zero-Day Discovery

   The U.K. National Cyber Security Center (NCSC) has warned that the widespread availability of AI-powered cyber tools has "almost certainly" led to a significant increase in the discovery of zero-day vulnerabilities. "Defensive AI-cyber tools have reduced the window of a vulnerability moving from zero-day to an n-day vulnerability, and have made patching a quicker process," NCSC said. "However, without correct and widespread configuring of this technology, many systems are still vulnerable to attackers using AI-cyber tools to identify and exploit system weaknesses. Additionally, an organisation’s internal patching and testing processes will need to evolve to meet the pace of accelerating vulnerability discovery. Attackers have subsequently displayed less caution over losing an access to achieve an objective, as the cost to replace is minimal."

2. Critical Systems Face Prolonged Exposure

   An analysis of roughly 383,000 CVEs disclosed from 1999 through September 2026 has found that the median time to patch a vulnerability exceeds a year for network appliances. About 2,000 CVEs (roughly 0.5%) have been linked to real-world exploitation. "The median vulnerability is patched in about two weeks on Windows workstations but in more than a month on Windows Servers," Microsoft said. "It stretches to 10+ weeks on Linux Servers and for applications running on macOS, and beyond a year on network appliances. That gap is the threat actor's window, widest on the critical systems that stay exposed the longest." The tech giant also said threat actors disproportionately target flaws that maximize impact and exposure and enable system takeover, particularly remote code execution, privilege escalation, and authentication bypass.

3. $4.5 Million Fraud Network Busted

   Authorities have arrested seven people allegedly involved in an investment fraud scheme that claimed potential victims in more than 50 countries, according to Europol. The operation caused estimated losses of at least $4.5 million. The "crime-as-a-service" offering was run by a company from Cyprus and Israel, and allegedly provided cybercrime groups with an assortment of trading websites and fraudulent call centers tasked with tricking victims into transferring their savings. These call centers operated from Albania, Kosovo, and North Macedonia. "More than 100 servers were seized and seven suspects arrested during coordinated action on 3 November 2026," Europol said. "Authorities searched 17 locations and seized servers, other evidence and assets." Like other fraudulent investment schemes, the operation leveraged deceptive advertisements to funnel people towards fraudulent investment platforms, promising them substantial, quick returns from cryptocurrency trading and foreign currencies. Although victims were encouraged to transfer a small amount, they displayed illusory gains to push them into transferring increasingly large sums. The operators resorted to delaying tactics to block payments when they attempted to withdraw their funds. "Behind seemingly legitimate platforms, supposed brokers used fictitious profits and sustained psychological pressure to persuade victims to invest more," Europol said. "Personal data collected through this process was sold to criminal groups operating call centers. Operators then contacted potential victims with supposed investment opportunities, turning their initial interest into repeated demands for money."

4. $250K Bounty for Critical Cloud Flaws

   Google has expanded its Cloud Vulnerability Reward Program (VRP) with a new top-tier reward for high-impact architectural security flaws, allowing researchers to earn $250,000 for Root-in-Cloud bugs, including tenant-isolation bypasses and complex cross-service logic flaws that let attackers gain full administrative control over arbitrary Google Cloud organizations. "To earn this premier reward, you must demonstrate full administrative control, the equivalent of 'roles/owner' or complete IAM control, over arbitrary Google Cloud organizations or projects with no prior access or special project setup," Google said. "Additionally, valid vulnerability reports demonstrating remote code execution (RCE) in underlying Google production infrastructure (Borg) or achieving root-in-prod will automatically be evaluated by the Google Cloud VRP panel for root-in-cloud eligibility."

5. Edge Blocks Scam Notification Abuse

   Microsoft has announced that its Edge browser will now automatically disable notifications from sites that push scam or scareware notifications, such as fake virus warnings or security alerts. "As of last month’s rollout of Edge 156, when Microsoft Defender SmartScreen or Scareware blocker detects a scam that was pushed through a notification, Edge will automatically disable notifications from the site that sent it," Microsoft said. "The next time Edge starts, an information bar explains what happened. If you believe a site was blocked incorrectly, you can review sites with blocked notifications and unblock them from Edge Settings, keeping you in control."

6. University Cryptojacking Charges

   Two Canadian men, Ryan James Roach, 35, and Mathiew James Stubbings, 41, have been indicted in the U.S. for hacking multiple U.S. universities and using the access to mine cryptocurrency. Both have been charged with conspiracy to obtain information from a protected computer and to cause damage to a protected computer, obtaining information from a protected computer, and intentional damage to a protected computer, which carry a maximum penalty of 10 years in prison and a $250,000 fine. "Between June 2016, and December 2019, Roach and Stubbings conspired to engage in a scheme to hack into computers, steal login credentials, and secretly mine cryptocurrency for financial gain," the Justice Department said. "They used virtual private servers in multiple countries, which were registered under false names. These servers transmitted malware and mining software to victim computers and stored stolen login credentials. Victims of the scheme included educational institutions in New York, Tennessee, North Carolina, and Massachusetts."

7. Ransomware Extortion Without Encryption

   Cybersecurity researchers have detailed an encryptionless extortion attack involving PAYLOAD ransomware targeting a manufacturing organization in the Middle East. "The threat actor obtained domain admin-equivalent control of the organization’s Active Directory environment and authored a malicious Group Policy Object (GPO) named PAYLOAD, linking it at the domain root," Kaspersky said. "Through that single object, the actor delivered ransom notes, hijacked the desktop wallpaper and lock screen, enforced a logon banner, and disabled the local administrator account across every domain-joined Windows workstation — all without dropping a ransomware binary or encrypting any data. The only ransomware we found in this incident was a PAYLOAD sample targeting ESXi on Linux servers." The attack represents a convergence of two trends: Living-off-the-land abuse of trusted AD infrastructure and a surge in extortion-only incidents.

8. AI Sandbox Escape Exposes Sensitive Files

   A vulnerability impacting Docker Sandboxes (CVE-2026-103916) could have been exploited to bypass file access restrictions, potentially exposing cloud credentials and other sensitive files on a developer's machine through a routine copy command. "The command used to copy files between a sandbox and the developer's computer (sbx cp) does not enforce these access restrictions," Endor Labs said. "An agent can exploit this weakness using what is known as a symbolic link, essentially a shortcut that points to another file or folder. By placing a malicious shortcut inside an approved workspace, the agent can trick a subsequent copy command into accessing files outside the sandbox's approved boundaries." The issue has been addressed in Docker Sandboxes version 0.51.0.

9. Smart TVs Keep Tracking After Opt-Out

   Does Opting Out of ACR Work?

   A new study has revealed that smart TVs running operating systems from Samsung, Vizio, and Roku continue to transmit data to automatic content recognition (ACR) endpoints even after users opt out of tracking in the devices' settings. "Opting out fully worked on only four operating systems. On Samsung and Vizio, traffic consistent with ACR kept flowing, and Roku's opt-out doesn't cover its own streaming service," according to a group of academics from Northeastern University. "VIDAA OS sends ACR data to servers run by Unruly over MQTT without encryption, so anyone on the network path between the TV and those servers can read it."

10. Cryptographic Proof for AI Outputs

    Anthropic has revealed that it's working on an open-source system called FlashProve to cryptographically verify an AI response came from a given model. "FlashProve is a system for provable inference of large Mixture-of-Experts (MoE) language models," Anthropic said. "FlashProve involves two parties: the model provider (the prover) and a user (the verifier). It is split into two phases: In the offline phase, the prover publishes a commitment to the model weights, which is a short fingerprint to pin down one exact choice of weights while the weights themselves remain hidden. The later inference claims will be checked against that commitment, i.e., the weight model committed to in this phase. In the online phase, upon requests from the verifier (i.e., prompts and the corresponding output tokens), the prover produces a proof file proving the following statement: The committed model produces these output tokens when evaluated. Anyone who holds the commitment, the prompt, and the reply can check it, without the weights and with limited compute power, and be convinced that the committed weights, run on this prompt, produce exactly these tokens."

11. FTP and Webmail Credentials Exposed

    DreamHost has warned of a data breach after an unauthorized third party gained access to the server that runs its web-based File Manager at files.dreamhost.com between August and October 23, 2026. "The unauthorized third party exploited a vulnerability in that software and was able to access the FTP/SFTP usernames and passwords of individuals who logged into this File Manager between approximately August 2026 and October 23, 2026," the company said. "The unauthorized third party was also able to reach certain webmail systems, which may have exposed the session information (the data that keeps a user signed in, including session credentials) of a limited number of webmail users. We believe this was a deliberate attack, and our team worked around the clock to contain it." DreamHost said the attacker may have accessed the credentials used to access the File Manager or webmail, along with the contents of emails and files in the FTP/SFTP server. There is no evidence that the attacker accessed control panel login information or customer billing details.

12. Pre-Auth RCE and Account Takeover

    The maintainers of Apache OFBiz have addressed 46 security flaws, including CVE-2026-68524, which could result in pre-authentication remote code execution, and CVE-2026-109928, which enables full account takeover due to an incorrect authentication algorithm implementation. The issues have been patched in Apache OFBiz 24.09.08.

13. Ransomware Encryption Flaws Exposed

    Cybersecurity researchers have uncovered encryption weaknesses in the updated HYFLOCK ransomware builds. The ransomware operation began to publicly name victims in October 2026, although evidence indicates that the group first appeared in underground forums in March 2026. As of writing, the group has listed 13 victims. "The October 17 build successfully encrypted files, registered a scheduled task, accessed network-share resources, and attempted to interfere with system recovery," Check Point said. "In an earlier October version, researchers identified a processing defect that could permanently discard portions of a file, potentially preventing complete recovery even with the correct decryption key. The October 17 build exhibited another issue. Larger files had only their first 4,096 bytes encrypted, leaving additional content accessible beyond that initial section."

14. Customer Identity Data Accessed

    DigiCert said it has identified an event involving unauthorized access to one of its business systems that stores information shared by customer representatives to validate their identity. The company said its certificate operations were not impacted. "Most of the data was limited to business contact information for customers: names, business email addresses, phone numbers, and business addresses," DigiCert said. "A small minority of customer accounts included additional personal data in the form of a customer-provided document such as a driver's license, passport, utility bill, or other document with name and address. The access could not write records, act as a validation approver, or issue certificates."

15. DeFi Hijack Drains $138K

    Threat actors have hijacked a little over a dozen DeFi websites registered with Name.com, including Flap, Kintsu, Pickle Finance and Origami Finance, ultimately stealing about $138,000 in assets. The sites have been found to be rigged with a malware kit that tricks visitors into approving transfers out of their wallets once they connect them to the compromised site. Vercel said it's aware of nine domains associated with the platform that were impacted. "Over about 45 minutes on Oct 31 (UTC), an account within an associated support team made changes to the nameservers associated with 15 domains registered with name.com," Name.com said in a post-mortem. "The domains were directed to a malicious page hosting Step Drainer malware."

16. Stolen Cloud App Credentials Abused

    Todyl has disclosed that an unknown threat actor has been abusing stolen Microsoft Entra ID application credentials and Azure DevOps identities to access MSPs' Microsoft 365 and Azure environments, reaching at least 27 organizations. "About 45 app registrations at roughly 18 organizations were targeted, and more than 33 of them authenticated successfully," Todyl said. "Through those apps the actor has reached 27 organizations so far, including the MSPs' downstream clients in government, energy, food and agriculture, transportation, construction and engineering, legal, education and nonprofits. It has run searches across about 25 tenants, downloaded 81 files and accessed around 2,279 mailbox items." The sign-in activity has originated from the IP address 199.19.77[.]84.

17. Syrian Hacker Gets 42 Months

    Ahmad Umar Agha (aka Th3Pr0), a Syrian national tied to the Syrian Electronic Army (SEA), has been sentenced to 42 months in prison in the U.S. for his involvement in an expansive hacking conspiracy organized and led by members of former Syrian President Bashar Al-Assad regime between Aug 2011 and January 2014. "To spread the former Syrian government's propaganda, Agha hacked approximately 47 Western media entities, businesses, non-governmental organizations (NGOs), and U.S. and allied government entities," the Justice Department said. "In one instance, Agha’s actions caused a flash crash in the U.S. stock market, resulting in a temporary $136 billion loss in the value of stocks making up the Dow Jones Industrial Average." Agha and his alleged accomplice, Firas Dardar, were first charged in June 2014. Dardar remains at large.

18. Malicious AI Search Results Steal Crypto

    A new piece of malware has been observed targeting AI agents creating cryptocurrency wallets. "A GitHub repository posing as a Solana starter kit, which ranks as the top result when an agent searches for one, contains malware that gives an attacker remote control of the victim's machine, including the crypto wallets on it," AIR Security said. The activity has been codenamed SolanaCry. The attack builds upon the foundation of Web Hole, where an AI agent, in its quest for finding answers to a problem, can inadvertently run a command suggested by an attacker and perform malicious actions. "To get a payload into search results, an attacker has two options," AIR said. "The first is to build a site of their own and grow its reputation with SEO, backlinks, content, time, until the search engine treats it as relevant and trusted. Once it ranks, they change the content and drop in the payload. The second is easier: find dead sites that still show up as ranked results, and use those to deliver it."

19. Android Banking Malware Spreads

    Thousands of Android phones belonging to retail banking customers in the Middle East, Turkey, and Africa (META) region have been compromised with the Mirax trojan between March and September 2026, leading to estimated losses worth millions of U.S. dollars. "Where unauthorized international transfers were reported, funds were sent to accounts abroad, some of which are suspected to be mule accounts," Group-IB said. "The campaign uses dynamically generated package names and impersonates 'Google Play Services' to evade user suspicion and signature-based detection." Like most Android malware, Mirax is used to facilitate device takeover (DTO) fraud by abusing Android's accessibility services. "With it, the attacker is able to see and control the compromised device in real time: reading credentials, intercepting one-time codes, capturing the PIN to unlock the device later, opening a banking app and moving money out to newly added beneficiaries and mule accounts abroad," Group-IB said. Campaigns using Mirax have been attributed to Aquafina, a threat actor known to be active since March 16, 2026.

20. AI Model Bypasses Task Instructions

    Irregular's evaluation of Zhipu AI's open-weight model GLM-5.3 across 13 offensive cyber scenarios using CyScenarioBench has found that the model "did not refuse any of the tested offensive tasks" and "repeatedly reached correct answers while violating explicit task instructions." The AI security company said these violations can be interpreted as a form of reward hacking. "Crediting the answer alone could mislead capability assessments and deployment decisions, while rewarding it during training could reinforce these instruction violations," it added.

One thing stands out this week: attackers don't always need to be smarter than the systems they're targeting. They just need to find what was missed, left open, or trusted a little too much. And with AI making some of that searching easier, the time between finding a problem and using it is getting shorter. Patching still matters, but so does checking whether the controls already in place actually work.

That's it for this week. Some of these problems have fixes. Others need a closer look at how people, tools, and systems are allowed to work together. The next big headache may not come from a new bug at all. It could be something that's been sitting there for years, waiting for someone to notice. See you next week.

from The Hacker News https://ift.tt/PQFLGqe
via IFTTT

CNCF Score project improved its security posture by joining the Docker-Sponsored Open Source Program

Score, a CNCF Sandbox project, recently joined the Docker-Sponsored Open Source (DSOS) Program to strengthen the security of its container images and release pipeline. In this post, the Score maintainers share what we adopted (Docker Hub, Docker Scout, Docker Hardened Images, the Docker GitHub Builder, and OIDC connections), the results we measured, and how other open source projects, within the CNCF and beyond, can apply the same practices by default.

The Opportunity

In September 2025, the CNCF announced a partnership with Docker to expand infrastructure support for project maintainers through the Docker-Sponsored Open Source (DSOS) Program. The partnership gives CNCF projects access to Docker’s security scanning tools, container registry, and best-practice resources at no cost.

This aligned closely with the discussions held at the Maintainer Summit NA 2025 in Atlanta, which centered on increasing collaboration across CNCF projects and demonstrating security best practices.

The Docker-Sponsored Open Source (DSOS) Program supports non-commercial open source projects with Docker tooling and infrastructure.

Eligible projects receive:

• Verified Docker-Sponsored Open Source badge
• Removal of rate limits for developers
• Access to Docker Scout for software supply chain management
• Insights and analytics
• Repository logo
• Improved discoverability on Docker Hub

Docker Hub

Before: Score publishes different container images: the CLIs of score-compose, score-k8s, score-helm and score-radius; and the sample-score-app used for demos and testing. We previously published them in the GitHub Container Registry here.

After: Through the DSOS Program, we now publish these images on Docker Hub, which increases their visibility and gives the community a verified, trusted source.

All the container images are now available on Docker Hub.

The program also provides usage analytics that show how the community uses these images. Here is an example:

Docker Scout

Before: As a CNCF project, Score follows the OpenSSF best practices. In addition, the OpenSSF Scorecard GitHub Action runs continuously. This was a solid foundation, but we had no dedicated security scanning tool in place.

After: The DSOS Program gave us access to Docker Scout, which we now use in our pull requests and on our container registry (Docker Hub). This gives us clear visibility into the CVEs introduced or fixed by each pull request and release.

The following GitHub Actions step uses docker/scout-action on every pull request to compare the image built from the PR branch with the one built from the main branch:

- name: Docker Scout Comparison between main branch and current PR branch
  uses: docker/scout-action@v1
  with:
    command: compare
    image: local://score-compose:pr-${{ github.event.number }}
    to: local://score-compose:main
    write-comment: true
    github-token: ${{ secrets.GITHUB_TOKEN }}
    organization: ${{ secrets.DOCKER_HUB_ORG }}

Here is an example of a comment posted by this docker/scout-action step in a recent Pull Request:

The comment details the comparison between the two images (before versus after): size, packages updated, added or removed, CVEs introduced and resolved, and compliance with our policies in place (run as non-root, no critical CVEs, no packages with AGPL v3 licences).

The analysis goes beyond the images themselves: it also covers the Go libraries and binaries they contain.

The Docker Scout console also provides a single view of CVEs, packages, base images, and policies across all of our container images, which makes it easy to see what is used where, and in which version.

Docker Hardened Images

When Docker made Hardened Images freely available under Apache 2.0, we saw an opportunity to simplify our security posture while staying compatible with our existing Dockerfiles and workflows, even though we were already using multi-stage builds and distroless base images.

Docker Hardened Images are minimal, security-focused container base images designed to reduce inherited risk in downstream projects. They are built and maintained with security and transparency as defaults, and offer:

• Minimal attack surface: Only required components are included.
• Non-root execution: Images run as non-root by default.
• Supply chain security: Includes published SBOMs and SLSA Level 3 build provenance.
• Active maintenance: Images are patched and rebuilt as vulnerabilities are disclosed.
• Open standards: All images are reproducible, open source, and licensed under Apache 2.0, making them compatible with CNCF governance and distribution models.

The migration was straightforward.

Take the score-radius CLI, which used a golang:alpine and a distroless images and now uses dhi.io/golang and dhi.io/static images. The changes required in the Dockerfile were minimal:

In the associated PR here, image size dropped by 0.3 MB while the number of packages stayed the same and the CVE count remained at 0. We could have stayed with Debian, but chose to move to an Alpine base image (DHI provides the two options):

The same applies to the NodeJS sample-score-app, which used nodejs on top of an alpine image and now uses a dhi.io/node image. The changes required in the Dockerfile were minimal:

In the associated PR here, 22 packages were removed (including the package manager and the shell), along with 2 CVEs:

Note: We were able to present a short walkthrough of our DHI integration during the CNCF webinar held on January 23, 2026, which accompanied the Docker Hardened Images announcement for CNCF projects.

Docker GitHub Builder

Although not directly part of the DSOS Program, we took the opportunity to adopt the new docker/github-builder GitHub reusable workflow to release our container images.

This model provides a build pipeline maintained in the Docker organization, with a version-controlled BuildKit environment, multi-platform builds distributed across runners where beneficial, and signed SLSA provenance recording both the source commit and the builder identity.

The trade-off is intentional. You retain control over when the build runs and which inputs it uses, while the build implementation itself lives in the Docker-maintained workflow rather than in per-repository job steps.

Before, the GitHub Actions workflow to release our container images was using this sequence of actions:

• docker/setup-buildx-action
• docker/login-action
• docker/build-push-action
• cosign sign

release-container-image:
  runs-on: ubuntu-latest
  permissions:
    id-token: write
    packages: write
  steps:
    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v3
    - name: Login to Docker Hub (docker.io)
      uses: docker/login-action@v4
      with:
        registry: docker.io
        username: ${{ vars.DOCKER_HUB_ORG }}
        password: ${{ secrets.DOCKER_HUB_RELEASE_TOKEN }}
    - name: Login to GitHub Container Registry
      uses: docker/login-action@v4
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}
    - name: Build and push docker image
      id: build-push-container
      uses: docker/build-push-action@v6
      with:
        context: .
        platforms: linux/amd64,linux/arm64
        push: true
        provenance: mode=max
        sbom: true
        tags: |
          ghcr.io/score-spec/score-compose:${{ github.ref_name }}
          ghcr.io/score-spec/score-compose:latest
          docker.io/scorespec/score-compose:${{ github.ref_name }}
          docker.io/scorespec/score-compose:latest
        build-args: |
          "VERSION=${{ github.ref_name }}"
    - name: Sign container image
      run: |
        cosign sign --yes ghcr.io/score-spec/score-compose@${{ steps.build-push-container.outputs.digest }}
        cosign sign --yes scorespec/score-compose@${{ steps.build-push-container.outputs.digest }}

After, this same workflow is now only using the reusable workflow docker/github-builder/.github/workflows/build.yml:

release-container-image:
  uses: docker/github-builder/.github/workflows/build.yml@v1
  permissions:
    contents: read
    id-token: write
    packages: write
  with:
    output: image
    push: true
    platforms: linux/amd64,linux/arm64
    sbom: true
    cache: true
    context: .
    set-meta-labels: true
    set-meta-annotations: true
    build-args: |
      "VERSION=${{ github.ref_name }}"
    meta-images: |
      ghcr.io/score-spec/score-compose
      scorespec/score-compose
    meta-tags: |
      type=ref,event=tag
      latest
    registry-identities: |
      - type: dockerhub
        registry: docker.io
        username: ${{ vars.DOCKER_HUB_ORG }}
        connection_id: ${{ vars.DOCKER_HUB_OIDC_CONNECTION_ID }}
  secrets:
    registry-auths: |
      - registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}

Docker GitHub Builder gives us a Docker-maintained build pipeline with signed SLSA provenance and SBOM attestations, helping consumers verify the builder identity and trace images back to their source commit. Signing uses GitHub OIDC, so we don’t need to manage long-lived signing keys. With caching enabled in our workflow, cache entries are also signed and verified before reuse, helping protect against cache poisoning. See the Docker GitHub Builder documentation for more information about its security model.

The following command verifies the signature on the attestation manifest for the selected image platform:

TAG=latest
PLATFORM=amd64

SIGNED_DIGEST=$(crane manifest scorespec/score-compose:$TAG \
    | jq -r --arg platformdigest \
    "$(crane digest --platform linux/$PLATFORM scorespec/score-compose:$TAG)" \
    '.manifests[] | select(.annotations["vnd.docker.reference.digest"] == $platformdigest) | .digest')

cosign verify \
    --experimental-oci11 \
    --new-bundle-format \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    --certificate-identity-regexp  '^https://github\.com/docker/github-builder/\.github/workflows/build\.yml@.*$' \
    scorespec/score-compose@$SIGNED_DIGEST

OIDC Connections

Most recently, with an update released on July 21, 2026, Docker introduced OIDC connections. This feature allows pulls and pushes to Docker Hub to use a short-lived token instead of a long-lived Organization Access Token (OAT).

An OIDC connection establishes a trust relationship between Docker and a trusted third party, so you no longer need to maintain long-lived credentials. Docker exchanges short-lived tokens with the other vendor, which can grant fine-grained access to your Docker resources.

Before:

With docker/login-action:

steps:
  - uses: docker/login-action@v4
    with:
      username: ${{ vars.DOCKER_HUB_ORG }}
      password: ${{ secrets.DOCKER_HUB_TOKEN }}

Or with docker/github-builder:

uses: docker/github-builder/.github/workflows/build.yml@v1
with:
  ...
secrets:
  registry-auths: |
    - username: ${{ vars.DOCKER_HUB_ORG }}
      password: ${{ secrets.DOCKER_HUB_TOKEN }}

After:

With docker/login-action:

permissions:
  id-token: write
steps:
  - uses: docker/login-action@v4 # v4.5.0+
    env:
      DOCKERHUB_OIDC_CONNECTIONID: ${{ vars.DOCKER_HUB_OIDC_CONNECTION_ID }}
    with:
      username: ${{ vars.DOCKER_HUB_ORG }}

Or with docker/github-builder:

uses: docker/github-builder/.github/workflows/build.yml@v1 # v1.15.0+
permissions:
  id-token: write
with:
  ...
  registry-identities: |
    - type: dockerhub
      registry: docker.io
      username: ${{ vars.DOCKER_HUB_ORG }}
      connection_id: ${{ vars.DOCKER_HUB_OIDC_CONNECTION_ID }}

By replacing a static, long-lived token with a short-lived one and making it issued on a per-workflow basis, we removed a credential that could otherwise be stolen and misused.

Wrapping Up

Participating in the Docker-Sponsored Open Source (DSOS) Program has been rewarding, and it has helped Score adopt a security-by-default foundation. Using Docker Scout, Docker Hardened Images, OIDC connections, and the Docker GitHub Builder has strengthened the security posture of our container images and brought broader benefits to the Score projects and repositories.

If you maintain a CNCF project or any open source project, we encourage you to explore the Docker-Sponsored Open Source (DSOS) Program. The security improvements were measurable, and the onboarding process was straightforward.

The full implementation across the Score repositories is tracked in GitHub issue #376.

Attending KubeCon NA 2026 in Salt Lake City? Feel free to connect with the Score maintainers during the Maintainer Summit on Sunday, Nov 8th and at the Kiosk #P-17B on Thursday, Nov 12th between 10:15am and 2pm, you will see Score in actions with the new Score Labspace!

Note: This work was completed after I joined Docker. It was, however, an initiative we wanted to pursue as CNCF project maintainers from the moment it was announced in September 2025, both to improve our security posture and to share what we learned with the broader community.

We hope this post helps you strengthen the security of your own projects.

from Docker https://ift.tt/IZFSh91
via IFTTT

Is Your Exposure Management Platform Leaving You Exposed? Five Tests to Find Out

A critical finding can move through several security tools and still leave the organization exposed.

The vulnerability has a severity score, and a ticket has reached the queue. Progress then depends on information the finding may lack: who owns the system, whether attackers can reach it, what protection exists, and how a change could affect the business.

Each missing detail creates another investigation, another handoff, and another delay.

An exposure management platform should connect discovery with a clear priority, an appropriate response, and evidence that protection has improved.

Continuous threat exposure management (CTEM) connects this work through scoping, discovery, prioritization, validation, and mobilization. These five tests establish whether a platform can support that process across infrastructure, identities, sensitive data, and external threats.

Security teams often have several records of the same asset. A cloud platform identifies an instance, an endpoint tool records its hostname, and an inventory lists an owner who has changed roles.

Cyber asset attack surface management (CAASM) connects those records, helping reveal stale information, missing ownership, and protection gaps.

The resulting view needs enough detail to support action: the asset’s owner, business purpose, assessment history, and security coverage. A system with no reported vulnerabilities should be distinguishable from one never assessed.

Disagreements between sources also need to remain visible. If an endpoint tool reports an active server while the inventory marks it retired, source records and update times help teams resolve the conflict.

Figure 1. CAASM connects source records with asset ownership, security coverage, and exposure context.

External discovery adds another perspective. External attack surface management (EASM) helps uncover what assets make accessible from the outside, including shadow IT, forgotten subdomains, and exposed services that internal tools never see.

EASM and CAASM work best together: CAASM maps what you know you own, while EASM validates that picture from the attacker’s point of view and surfaces what’s missing. Every unmanaged asset EASM finds can be fed back into CAASM, closing coverage gaps and giving each asset an owner. EASM also covers brand exposure, extending discovery to phishing sites, fraudulent profiles, and brand impersonation, so the same external view that finds your unknown assets also finds the lookalikes attackers build to target your customers and employees.

Read CAASM Was Never Meant to Stand Alone to see how asset intelligence supports the decisions and actions that follow discovery.

2. Explain Which Exposures Require Action First

Prioritization depends on understanding what an exposure actually puts at risk. A customer-facing application may carry the same severity score as an isolated development system while presenting very different business risk.

Prioritization should connect:

• Reachability and exploitability: Whether attackers have a usable path to exploit the weakness.
• Threat activity: Whether attackers are targeting the vulnerability or technology.
• Business impact: What the system supports and what compromise could affect.
• Existing protection: Whether relevant controls cover the system and are enforced.

Those conditions change. New exploitation activity may accelerate a response, while a disabled protection may invalidate an earlier assessment.

External threats need similarly specific reasoning. A fraudulent support account approaching customers may require rapid disruption; an abandoned company profile may first need ownership review.

See what the 2026 Exposure Gap Report reveals about prioritization and remediation performance.

3. Validate the Exposure and the Proposed Response

A clear priority can still stall when the system owner lacks confidence in the proposed change.

Validation needs to establish what the exposure allows and how the response could affect operations.

Identifying vulnerable software, confirming reachability, and demonstrating exploitability establish different things. A platform should distinguish observed evidence from analysis and untested assumptions. Attack-path relationships also need supporting evidence and clear limitations.

The proposed response requires separate assessment. A patch may depend on application testing and a maintenance window. An intrusion prevention system protection may require observation in Detect mode before enforcement.

Evidence should address the action’s scope, dependencies, false positives, performance impact, and recovery options. Following a proposed change through this assessment reveals what the platform establishes and what teams must investigate themselves.

Knowing what to fix first is great, but only if the fix happens quickly. The permanent patch often waits on testing, approval, and a maintenance window, and the exposure stays open the whole time. That’s true whether the weakness is on an internet-facing server or a phishing site targeting your customers.

Speed comes from confidence. Teams hesitate when they can’t say what an action will touch. When the platform already knows the asset, its owner, the active threat, and the controls in place, that hesitation disappears. Many Check Point Exposure Management customers remediate safely within one hour, because the context is complete and the safety checks are built in.

To test this, take one real finding and follow it from priority to protection:

• Owner: Is the right person assigned automatically?
• Safety: Is the action validated before it runs, including its impact and a way back?
• Execution: Does it run through the controls you already have, whether a virtual patch, a configuration change, or a takedown?
• Confirmation: Is the result verified, with the permanent fix still tracked?

Interim protection buys time, but it shouldn’t replace the long term fix.

Figure 2. Safe remediation connects observation, validation, action, and confirmation.

Speed holds up at scale. Between January 1 and October 26, 2026, an airline group completed more than 1,500 takedowns of profiles impersonating its airlines and support teams, combining analyst review with automated remediation.

And when an action fails, the exposure should stay visible with a clear next step.

Read Safe Remediation: Confident Remediation in Production to see how validation, execution, and confirmation work together.

5. Show What Changed and What Remains

A completed action needs evidence of the resulting state.

A patch may miss unavailable systems. A policy update may exclude an intended asset. A takedown request may be accepted before the account disappears.

Verification should establish whether the vulnerability remains, protection is enforced, or malicious content has been removed. Monitoring should identify recurrence.

Reporting must distinguish removed vulnerabilities, interim mitigations, completed takedowns, and accepted risk. Each leaves different responsibilities outstanding.

Mean time to remediate (MTTR) requires agreed starting points, completion criteria, and treatment of temporary protection.

Tracking assignment, approval, execution, and verification separately reveals delays.

Recurring findings, failed actions, and aging mitigations can expose operational problems another scan will not resolve.

Apply the Tests Across Vendors

Platforms approach these requirements from different foundations. The five tests provide a consistent basis for evaluating coverage, evidence, and action.

Check Point Exposure Management combines internal asset intelligence, external discovery, threat intelligence, and brand protection with prioritization, exploitability validation, and safe remediation. It spans infrastructure weaknesses, phishing, and brand impersonation, supporting action through existing controls and takedown workflows.

Bring Intelligence Through to Safe Action

The five tests follow an exposure from discovery to a confirmed response. Each stage should give the next team enough reliable information to act while keeping unresolved work visible.

Check Point Exposure Management carries asset and threat context into responses to vulnerabilities, control gaps, and external threats. Proposed actions are evaluated before enforcement, with approved responses coordinated through supported Check Point and third-party technologies.

That connection helps organizations strengthen protection while accounting for production constraints and building on existing investments. It creates a traceable path from an identified exposure to an evaluated, implemented, and confirmed response.

Book a demo to see how Check Point Exposure Management carries an exposure from discovery through safe remediation and verified protection.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/j6xC8Jg
via IFTTT

Hackers Exploit Patched Apple Flaw to Deliver Info-Stealing Malware, CISA Says

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Wednesday added a medium-severity security flaw impacting multiple Apple operating systems to its Known Exploited Vulnerabilities (KEV) catalog, following reports of active exploitation.

The vulnerability in question is CVE-2024-27834 (CVSS score: 5.5), a case of improper authentication that could allow an attacker with arbitrary read and write capability to bypass Pointer Authentication.

It was addressed by Apple in May 2024 with improved checks in iOS 16.7.8 and iPadOS 16.7.8, iOS 17.5 and iPadOS 17.5, macOS Sonoma 14.5, tvOS 17.5, watchOS 10.5, and Safari 17.5. The vulnerability was demonstrated as a zero-day at the Pwn2Own Vancouver hacking contest held in March that year.

The addition of CVE-2024-27834 to the KEV catalog follows a report from Sekoia that threat actors possibly linked to Russia exploited previously patched vulnerabilities in Safari and Google Chrome to deliver malware capable of harvesting browser and device data.

The activity has been attributed to APT29 (aka Cozy Bear and Midnight Blizzard), a state-sponsored hacking group affiliated with Russia's Foreign Intelligence Service, with "moderate to high confidence."

The attacks involve three initial access pathways – compromised legitimate websites, fake sites masquerading as popular websites, and a supply chain attack aimed at Plerdy SEO Tracker – to serve malicious JavaScript that triggers the vulnerability and ultimately deploy the information-stealing payload after profiling the visitor's device.

The zero-click exploit chain combines CVE-2025-43529, a remote code execution flaw in WebKit, and CVE-2025-43529, the pointer authentication codes (PACs) bypass, to execute a JavaScript payload designed for browser cookie theft.

In light of active exploitation, Federal Civilian Executive Branch (FCEB) agencies are recommended to apply the necessary patches by November 18, 2026.

from The Hacker News https://ift.tt/cxGKgir
via IFTTT

OpenAI AI Pipeline Generates 948 Linux Root Escalation Exploits in 30-Hour Run

OpenAI on Wednesday detailed a pipeline that employed an upcoming cyber-focused artificial intelligence (AI) model to validate and patch 948 local privilege escalation vulnerabilities in Linux for $1.2 million in API costs.

"Our prototype identified and analyzed 2,308 candidate Linux kernel findings, dynamically reproduced 1,724 vulnerabilities, and produced 948 local privilege escalation (LPE) exploits that could allow an unprivileged local user to gain root access," the AI company said.

The findings build upon 24 LPE exploits that OpenAI revealed were discovered by its GPT‑5.5‑Cyber model back in June 2026. The latest research turns this process into an agentic pipeline comprising five stages -

• Vulnerability discovery, where agents identify high-value audit targets (i.e., parts of the codebase that are security-relevant and reachable by low-privileged users) and look for candidate findings
• Dynamic validation, where agents attempt to reproduce each candidate in a sandboxed environment and preserve runtime evidence
• Exploitability assessment, where agents test whether validated vulnerabilities could be abused to facilitate information disclosure or LPE and devise a proof-of-concept (PoC) exploit
• Patch generation, where agents generate patches for the identified vulnerability
• Human review, where security researchers review the exploit, patch, and proposed severity before it's reported to the maintainers

"In a run in mid-October 2026, our pipeline using an upcoming cyber model dynamically reproduced 1,724 vulnerabilities [within 30 hours] and generated PoCs for 291 information leak vulnerabilities and 948 working local privilege escalation (LPE) exploits for a commonly used Linux distribution," OpenAI said.

"The total run cost $1,213,430 in API credits, or $1,279 per LPE exploit. To the best of our knowledge, the agents in this pipeline discovered and used at least 10 novel Linux exploitation techniques."

At a high level, these include -

• Two new persistent elastic objects to spray objects inside the target kernel cache
• Two new page grooming techniques to improve exploit reliability
• Five new data-only techniques to obtain privilege escalation directly or via an arbitrary write
• One technique that involves arbitrary type confusion

The development is once again an indication of how frontier AI is redrawing the contours of cybersecurity, accelerating vulnerability discovery and exploitation, and at the same time helping defenders reliably address defects, albeit through additional instructions and iterations, before attackers can use them, and make it "cost prohibitive" for bad actors to exploit software.

In a report published last month, VulnCheck categorized AI-assisted vulnerability discovery as a "growing risk category" that turbocharges novice hackers, who now require little to no technical expertise to detect software vulnerabilities.

The access to AI models is not just limited to defenders, but also bad actors who can leverage the same capabilities to discover and weaponize new zero-days and expand the pool of viable targets with minimal effort.

According to insights from Google Threat Intelligence Group (GTIG), the number of vulnerabilities disclosed per month has more than doubled, rising from 5,045 in January 2026 to 10,740 in August 2026. The number of vulnerabilities classified as high-risk has surged from 131 disclosures in January 2026 to 350 in August 2026, a 167% growth.

"The widespread availability of AI-powered cyber tools has almost certainly led to a significant increase in the discovery of zero-day vulnerabilities," the U.K. National Cyber Security Centre (NCSC) said in an assessment published Tuesday.

"Defensive AI-cyber tools have reduced the window of a vulnerability moving from zero-day to an N-day vulnerability, and have made patching a quicker process. However, without correct and widespread configuring of this technology, many systems are still vulnerable to attackers using AI-cyber tools to identify and exploit system weaknesses."

The NCSC also pointed out that organizations will have to evolve their internal patching and testing processes to meet this new pace of vulnerability discovery.

"Attackers have subsequently displayed less caution over losing an access to achieve an objective, as the cost to replace is minimal," it added. "Cyber capabilities are now used for a broader range of activity due to the lower risk involved, making it easier for adversaries to access information and use it operationally."

OpenAI said the rate of vulnerability discovery by frontier models needs to be matched by automated patch generation to secure software and to limit the exploitation window.

"With human expert-guided iteration, we believe AI-generated patches can be functionally correct, aligned with existing coding styles, and robust to attack variants," OpenAI said. "For the near and medium term, having access to a low-privileged account on an operating system that isn't up-to-date on its latest available patches should be considered functionally equivalent to root access for a well-resourced threat actor."

from The Hacker News https://ift.tt/zixTDPC
via IFTTT

phpIPAM version 1.9 released

New version of phpipam (1.9) released.

from phpIPAM IP address management https://ift.tt/pKmZWaS
via IFTTT

SonicWall Won't Patch EoL GMS Flaws That Could Expose Files, Alter Database Records

SonicWall has warned of two vulnerabilities impacting end-of-life Global Management System (GMS) systems that it said will not be patched.

Details of the security flaws, which affect SonicWall GMS 9.5.2 and earlier versions, are below -

• CVE-2026-109593 (CVSS score: 9.1) - An unauthenticated file read vulnerability that could allow an attacker with network access to read internal GMS files, potentially exposing sensitive information.
• CVE-2026-109594 (CVSS score: 6.8) - A post-authentication SQL injection vulnerability that could allow an authenticated attacker to access or modify information stored in the GMS database under specific conditions.

"The affected product has reached End-of-life (EoL)," SonicWall said in a Tuesday alert.

"As a result, no remediation or security update will be released for these vulnerabilities. Organizations using the product should be aware of the associated security risks and are strongly encouraged to upgrade to the SonicWall Network Security Manager (NSM)."

The development comes less than a month after SonicWall shipped fixes for CVE-2026-102255 (CVSS score: 10.0), a critical pre-authenticated server-side request forgery (SSRF) flaw that could have allowed an attacker to reach internal functionality and perform unauthorized operations.

The vulnerability has since come under active exploitation in the wild, with telemetry data from Previdian recording 2,541 attack attempts from eight unique IP addresses from Singapore and the U.S. since October 9, 2026. As many as 30 exploitation attempts were registered on November 3, 2026.

from The Hacker News https://ift.tt/wPjNUOx
via IFTTT

Researchers Uncover Prompt Adware Hidden in OpenAI Codex Jailbreak Toolkit

Cybersecurity researchers have disclosed details of an OpenAI Codex jailbreak bundle that's designed to modify an artificial intelligence (AI) agent's trusted instructions to insert advertisements for a third-party AI gateway.

The phenomenon has been codenamed prompt adware by Check Point Research.

Called Haiou (meaning Seagull in Chinese), the jailbreak modifies OpenAI Codex's configuration files to inject advertisements for the jailbreak author's website into subsequent agent responses.

"The advertised service is an opaque, OpenAI-compatible LLM gateway, a middleware between an application and an LLM provider," Check Point Research said in a technical report. "The likely business model is to use the freely distributed jailbreak bundle as an acquisition channel for the paid gateway service."

Adware is a type of software that displays unwanted advertisements, which can appear on users' computers or mobile devices, often in the form of pop-ups or banners. Prompt adware extends this sketchy behavior to AI agents by means of a jailbreak that defeats the model's safety training and content guardrails.

The idea is to persistently modify the agent's global instructions through natural language to influence future responses. This, in turn, causes common greetings or activation words like "Seagull," "hi," "hello," "hey," "yo," and "are you there?" to trigger an advertisement for "zz.aiapi2025[.]top."

Haiou attempts to jailbreak a model by using several prompt injection techniques, such as role-playing and reframing cybersecurity-related requests into a Capture The Flag (CTF) scenario. In addition, it installs security-focused skills devoted to penetration testing, cracking, and reverse engineering.

However, it doesn't stop there. The bundle also injects persistent ads into the global agent instruction file to promote the LLM gateway website. On GitHub, "haiou-codex" is advertised as a "local enhancement configuration package" that adds a "Chinese technical personality and security research workflow to Codex." As of writing, the repository has been forked 77 times and starred 403 times since it was made available on July 10, 2026.

It's worth noting that Codex is not officially available in mainland China, suggesting that the service is likely aimed at individuals or organizations wanting to try out Western AI coding assistants.

What's more, the jailbreak has been bundled within Codex-X, an open-source Chinese visualization tool for configuring Codex through a graphical user interface.

"The behavior is introduced through natural-language instructions and configuration, rather than a traditional executable payload that users and security teams may more readily recognize as software behavior," Pedro Drimel Neto, malware analysis team leader at Check Point, said.

While serving an ad may seem relatively harmless in the larger scheme of things, the findings demonstrate how a bad actor could introduce undesirable behavior through third-party skills or configurations, leading to supply chain attacks.

"As AI agents become part of enterprise environments, the prompts, Skills and third-party components influencing their behavior become part of the trust chain too," Neto said.

from The Hacker News https://ift.tt/Un7aQ5s
via IFTTT

APT29-Linked Hackers Hijack Web Analytics Script to Deliver iOS and Android Exploits

The Russia-linked threat actor known as APT29 is said to be behind a large-scale watering hole campaign targeting iOS and Android users through compromised websites, fake domains, and a supply chain attack involving a Ukrainian web analytics service called Plerdy SEO Tracker.

"The injected JavaScript code collects browser and device attributes," Sekoia researchers Amaury-Jacques Garçon and Félix Aime said in a technical report shared with The Hacker News. "Then, the delivery infrastructure delivers a platform-specific N-day exploit chain targeting either iOS or Android."

The end goal of the attacks is to serve payloads capable of stealing browser cookies, and in some cases, Wi-Fi passwords or full mobile device data. The activity, codenamed Poisoned Source, was discovered by the French cybersecurity company in mid-October 2026.

A defining aspect of the campaign is the use of three infection vectors -

• Compromise of legitimate websites to inject malicious JavaScript
• Lookalike sites masquerading as high-profile websites in the U.S. ("america250[.]holiday"), Ukraine, Czech Republic, and Bulgaria
• Supply chain compromise of Plerdy SEO Tracker between August 27 and September 3, 2026, by injecting malicious code into "a.plerdy[.]com/public/js/click/main.js"

Some of the compromised websites include a major industry trade association representing U.S. companies operating in the chemical industry, a far-right European political party, and a Bulgarian military-related website. It's suspected that the watering hole campaign may have been designed to target specific individuals rather than a broad effort.

"It remains unclear whether the attackers intended to target visitors to specific websites or sought to compromise as many unpatched mobile devices as possible, indiscriminately exfiltrating data before selectively identifying and exploiting information of interest," Sekoia said.

"However, several of these sites are likely to attract high-value or strategically important visitors in the context of the Russia-Ukraine war. This supply chain attack spread through high-value targets, such as army, special forces, and military equipment (ballistic, UAV) websites."

Regardless of the method employed, all roads lead to the same payload: a JavaScript loader that profiles the visitor's device and web browser, and then serves appropriate next-stage malware. For iOS users, it leads to an exploit kit called DarkSword to harvest cookies and full device data.

On Android, the malware is equipped to exfiltrate Chrome data and Wi-Fi passwords without establishing persistence. No less than three different exploits have been identified -

• Class A, which targets iOS devices running iOS 16.7 and exploits CVE-2025-43529 (the same vulnerability exploited by DarkSword) and CVE-2024-27834 to deliver JavaScript malware for cookie theft.
• Class B, which targets iOS devices running iOS 18.5 and exploits the DarkSword exploit chain comprising CVE-2025-43529, CVE-2026-20700, CVE-2025-14174, CVE-2025-43510, and CVE-2025-43520 to deliver JavaScript malware for full device data exfiltration. This includes SMS messages and iMessages; Apple Mail Envelope Index and Protected Index SQLite databases; voicemail; WhatsApp and Telegram databases; iCloud Keychain, Wi-Fi passwords; contacts; call history; Safari browser history and cookies; photos; and data from Apple Health, Calendar, Notes, and iCloud Drive.
• Class C, which targets Android devices running Chrome versions from 139 through 145 (but explicitly excluding version 143 for reasons that remain presently unknown) and exploits CVE-2026-3910 and CVE-2025-27038 to achieve remote code execution, sandbox escape, privilege escalation, and ultimately deliver AndroSnitch to collect Chrome data and Wi-Fi passwords.

In all three cases, the exfiltrated data is sent to the "ad.starx-net[.]com:8881/telemetry/v12" endpoint. The Android attack chain incorporates a check to determine whether the targeted device is a Samsung Galaxy S25 Ultra by examining its model identifier (i.e., SM-S938B). If the device matches, the exploitation activity is terminated.

AndroSnitch derives its name from its similarities to ANDROSNATCH, a Chrome cookie-stealing payload that Google documented in August 2024 in connection with a suspected APT29 watering hole campaign, which targeted Android users visiting a Mongolian government website by leveraging a Chrome exploit chain involving CVE-2024-5274 and CVE-2024-4671.

"This operation also confirms the continued reuse of CSV [Commercial Surveillance Vendors] mobile exploit frameworks, such as DarkSword, by state-sponsored intrusion sets," Sekoia said. "The adoption of packaged N-day exploit chains lowers the cost and technical threshold required to conduct advanced mobile exploitation."

Coruna and DarkSword Kits Evolve

The development comes weeks after iVerify and Report URI detailed the P7 variant of DarkSword being delivered via half-click attacks that leverage ad-based infrastructure. In one case, the exploit is said to have been propagated through a malicious Instagram ad themed around the World Cup and served from "ad-track[.]live."

The other pathway is part of a criminal campaign dubbed DeadTag, in which attackers acquire expired domains behind old analytics and advertising tags that are still loaded by thousands of websites. The idea is to serve malicious JavaScript to iPhone visitors and silently do the attacker's bidding.

"It checks who's visiting," Report URI said. "Search engines, security scanners, automated browsers and anything else that looks like a bot gets nothing."

The script then interacts with the attacker's server, which then decides the destination to which each visitor has to be redirected. The iPhone exploit paths that take advantage of DeadTag lead to the Coruna exploit kit for older iPhones running iOS version 13 to 17.2.1 and DarkSword P7 for iOS devices running 18.4 to 18.7.

"These are not phishing pages or fake app downloads, both kits attack the browser itself," Report URI's Scott Helme said. "Simply opening the page is enough for your device to be compromised. There's nothing to tap, you don't need to click any link, nothing to install and no warning. If the iPhone is running a vulnerable version of iOS, the kit breaks out of the browser and installs spyware on the device."

Other schemes lead to decoy Google redirects, betting and casino scam sign-up pages, search advertisements for car deals and dentists, and fake surveys and "you've won" prize pages. More than 660 expired and re-registered domains are part of the DeadTag network.

According to an analysis published by Zimperium zLabs, campaigns distributing Coruna and DarkSword exploit kits have continued to evolve, with 608 domains delivering Coruna-family code as of October 2026.

Although Coruna was initially developed by a nation-state actor for highly targeted operations, its subsequent leak following initial disclosure has made the toolkit widely accessible to multiple threat actors for their own campaigns.

In many cases, the lure sites have been found to explicitly instruct visitors to exit their in-app browser or alternative iOS browser and open the link in Safari so as to trigger the exploit chain depending upon the device operating system.

"Targets running iOS 17.2.1 or earlier receive the legacy Coruna framework (exhibiting byte-identical JavaScript payloads across multiple recovered configurations)," security researcher Santiago Rodriguez said. "Conversely, devices running later iOS builds receive a DarkSword-derived execution chain."

"The analyzed distribution footprint spans dating portals, AI-companion platforms, cryptocurrency promotions, media streaming services, and – in several instances – compromised legitimate sites serving the kit via hidden iframes."

from The Hacker News https://ift.tt/pB4fSQl
via IFTTT