The $40 supply chain attack: How internal domain collisions became a CI/CD nightmare

For $40 in domain registration fees, we gained the technical capability to inject malicious code into AbsorbLMS’s CI/CD pipeline. Over six months, their build systems sent 99,351 queries to domains we controlled, each request representing an opportunity to deliver compromised software packages that could have ultimately reached 34 million learners.

Internal domain collision vulnerabilities represent one of the most underestimated supply chain risks in modern infrastructure. During our ongoing research, we've identified this vulnerability pattern affecting thousands of organizations, from Fortune 500 companies to critical infrastructure providers. Unlike traditional supply chain attacks that target public repositories and trigger security alerts, these attacks exploit trust in internal domains, making them nearly impossible to detect with standard security controls. This case-study is a technical deep-dive into how this seemingly minor misconfiguration created exploitable access to supply chain infrastructure that could have silently affected millions of users.

TL;DR?

• Cost of attack: $40 (domain registration)
• Duration: 180 days(*) of continuous access
• Traffic observed:
• 2.15 million requests from 8,672 unique IPs
• 99,351 requests for software packages
• 26 developer accounts clear-text credentials
• 10,152 JWT tokens
• 171 yaml deployment specifications received
• Impact: Complete CI/CD pipeline exposure - GitLab webhooks → Bamboo builds → Artifactory packages
• Response: "It's just QA, behind a VPN, low risk"
• Current status: Domains expired January 4, 2026. Following publication of this case study, Absorb requested we renew and transfer the domains back to them, which we did on January 23, 2026.

This case study isn’t about DNS leaks or WPAD attacks. It’s about what happens when automated build pipelines trust “internal” domains that someone else controls in the public namespace.

(*) A note on timeline: Our tooling automatically registered the domains defensively in January 2025 after discovering the potential collision. We began reporting the issue to AbsorbLMS in May 2025 and offered to transfer the domains at no cost. The 180-day observation period reflects the time between activating our sinkhole (to document the scope of exposure) and the domains’ eventual expiration, during which we repeatedly attempted coordinated disclosure and remediation.

Request for comment

Before publishing, we provided AbsorbLMS with the opportunity to comment on our findings. Their responses appear throughout in pink-highlighted blocks, representing their internal investigation results and risk assessment. We've included these comments to present both perspectives on this case study.

Who is AbsorbLMS?

AbsorbLMS is a cloud-based Learning Management System trusted by over 2,900 organizations and used by more than 34 million learners worldwide.

Their customers include Fortune 500 companies like Sony, Toyota, Johnson & Johnson, and Samsung. The platform handles employee training, customer education, compliance management, and certification programs, making it a high-value target with access to sensitive organizational data.

A brief refresher on internal domain name collisions

An internal domain name collision occurs when a hostname or service name intended to resolve only within a private network is inadvertently resolved through the public Domain Name System (DNS).

As an analogy: imagine calling out “John” in a small office where there’s only one John. Now imagine shouting “John” in a crowded airport. Chances are someone other than your “office John” will respond. The context that made the name unambiguous in the small office no longer applies in public.

To prevent this, best practice has long been to use non-routable, reserved suffixes such as .local for internal domains. Unfortunately, many organizations built their internal infrastructure years ago using domain names under top-level domains (TLDs) that didn't exist at the time or that they didn't know existed (like .cloud, .dev, or .ad). They assumed these domains were safe because they weren't routable. But as ICANN expanded the DNS root zone and introduced hundreds of new TLDs, those assumptions quietly broke. The problem has gotten worse with remote work. When employees worked on-premise, their devices always used internal DNS servers. Now, with hybrid work and VPNs that don't always force-tunnel all traffic, corporate devices increasingly use public DNS resolvers, causing internal queries to leak externally.

The critical risk most people miss is that it's not just about leaked credentials or proxy configurations. In modern DevOps environments, these collisions can compromise your entire software supply chain.

Initial discovery: Following the TLS certificates

As part of our broader research into internal domain name collisions, we developed several techniques and tools to identify internal namespaces that are leaking externally. One particularly effective approach involves the analysis of TLS certificates issued by internal Certificate Authorities (CAs).

Unlike public CAs, which require proof of domain ownership before issuing a certificate, internal CAs can issue certificates for any Fully Qualified Domain Name (FQDN) that is assumed to exist within the organization’s private namespace regardless of whether that domain is actually registered or owned publicly.

By design, the internal domain name of the issuing CA, as well as internal hostnames and service names appear in the certificate subject and/or in the Subject Alternative Name (SAN) extension. This makes these certificates a useful signal for identifying internal namespaces that may overlap with the public DNS.

During this analysis, we discovered certificates issued by an internal CA named AbsorbLMS CA, with certificates issued to the domain absorb.ad. The SAN extension revealed additional internal hostnames, including references to a second internal namespace, blatantmedia.ad, alongside multiple subdomains (e.g., sandbox, integrator, artifactory, etc.)

At this point, two things immediately stood out:

1. Both absorb.ad and blatantmedia.ad were valid, publicly routable Fully Qualified Domain Names under the .ad country-code TLD.
2. Neither domain was publicly registered at the time.

This is the textbook definition of an internal domain collision: the organization using a domain name internally and the entity owning the same domain in the public namespace are different.

Defensive Registration: $40 and a DNS Server

To prevent malicious exploitation and measure the real-world impact, we registered both domains for approximately $40 total ($20 per domain).

As with all the other domains registered during our research, our intent was explicit and consistent:

• prevent threat actors from exploiting the collision,
• document the scope of exposure,
• responsibly report the issue to the affected organization,
• and collaboratively transfer the domains back to their rightful owner.

We configured dedicated nameservers to passively log all incoming DNS queries. Once the domains were registered and delegated to our nameservers, the traffic started flowing immediately. Not just sporadic background noise, but sustained traffic characteristic of a major internal infrastructure. This included name resolution attempts typically associated with corporate environments, such as wpad lookups, as well as hostnames resembling internal CI/CD environments (bamboo.absorb.ad, artifactory.absorb.ad) and clearly structured production-style systems (euw1-prd-app-01.absorb.ad, can1-prd-app-01.absorb.ad, and similar patterns).

Given the volume of traffic we received, we quickly ingested all telemetry into Elasticsearch for analysis.

Initial disclosure attempts: A 90 days journey

Before diving into what we found, here's what happened when we tried to report it.

May 9, 2025 - Sent detailed report to security@absorblms.com

Result: Ticket creation failed. 😑

Absorb comment: the failure occurred in the automated Jira ticket creation workflow but the message itself was received

May 12, 2025 - Sent private messages via LinkedIn to AbsorbLMS and their CTO

Result: No response. 😑

May 15, 2025 - Published a public LinkedIn post tagging Absorb Software

Result: CTO finally responded to our private message:

Absorb comment: The outreach to our CTO arrived without established context, credentials, or a validated reporting trail that would allow an executive to safely determine whether it was a legitimate security disclosure, general inquiry, or potentially harassment/social engineering. Directing the reporter to our formal security intake is the appropriate channel to authenticate submissions and ensure proper handling through established security processes.

May 15, 2025 - Sent detailed report to security@absorblms.com (again)

Result: Ticket creation failed (again). 😑

Absorb comment: The GRC team escalated this report to IT on May 21, 2025

May 19, 2025 - Sent a message via website contact form, explaining the issue at a high level and requesting the security team reach out to us.

Result: Within 6 minutes, we received an email and a phone call from Marcela... from sales 😑. We explained the vulnerability (again). She thanked us and added us to the marketing mailing list.

June 3, 2025 - Sent a follow up private message to AbsorbLMS’s CTO via LinkedIn

Result: No guaranteed response-time SLA… We will respond within 90 days.

Absorb comment: This guidance wasn’t meant to delay action, but it was meant to ensure the disclosure was handled through the proper process to validate technical claims, coordinate remediation, and communicate responsibly. Under these circumstances, we believe the memes suggesting that our company was negligent or non-responsive are unfair and unwarranted.

June 4, 2025 - Received a generic acknowledgement email from Absorb’s security team

August 7, 2025 - Received a substantive response, exactly 90 days after our initial report to security@absorblms.com (May 9, 2025). But here's the twist: AbsorbLMS framed our vulnerability disclosure as a "bug bounty submission" and offered $2,000 under their bug bounty program terms, terms we never agreed to and that would have restricted our ability to publish this research.

Absorb comment: The report was triaged through our bug bounty program as our standard mechanism for tracking vulnerability disclosures, which allows up to 90 days for initial response. The $2,000 offer was intended to acknowledge the report consistent with our established process, not to restrict independent research. Researchers can decline bug bounty participation and associated terms.

We clarified this was independent research, not a bug bounty submission. At that point, the conversation shifted from technical teams to legal leadership. And the narrative became "QA environment only," "behind a VPN," and "low risk.”

Absorb comment: Information Security reports to Legal at Absorb, so legal coordination is standard procedure and doesn't indicate deprioritization. We conducted internal review and commissioned an independent penetration test to assess CI/CD integrity and environment boundaries. We don't dispute the observed traffic logs, but notes that external observations don't necessarily establish whether controls could be traversed to reach production systems.

Meanwhile, our logs told a different story.

Deeper traffic analysis: Not low risk

Given the lack of traction following our initial disclosure attempts, we decided to proceed with a deeper analysis of the traffic reaching the registered domains. The goal was not to speculate about impact, but to identify concrete, observable behaviors and determine whether the exposure resulted in meaningful attack primitives.

To do this, in addition to collecting DNS resolution attempts, we configured wildcard A records pointing all subdomains to a server we controlled, allowing us to passively observe how internal systems attempted to interact with what they believed were trusted internal services. DNS telemetry alone can show that a hostname is being resolved, but analyzing application-layer traffic reveals how that hostname is being used, whether by browsers, automated tooling, build systems, authentication mechanisms, or operating systems.

Between July 8, 2025 and January 4, 2026 (180 days), we recorded:

• 2,150,450 total requests
• 11,624 requests per day average
• 8,672 unique source IPs

We also learned more about AbsorbLMS internal infrastructure:

• bamboo.absorb.ad: 398,867 requests - Their CI/CD orchestration system
• artifactory.absorb.ad: 222,460 requests - Their package manager repository
• sonarqube.absorb.ad: 925,058 requests - Their code quality analysis
• 111 GitLab webhook events - Every code push notified the absorb.ad domain

Every layer of the DevOps pipeline was exposed.

Absorb comment: The observed traffic was associated with our QA environment using dummy/test data. We commissioned an independent penetration test focused on CI/CD integrity and environment boundaries, which found no viable path to penetrate our systems, introduce malicious code into our builds, or pivot from QA to production. Observable requests to internal services don't necessarily establish that an external party could authenticate, issue commands, or deliver packages accepted downstream.

The real story: Supply chain takeover via package managers

Here's what most people miss about domain collisions: they're not just about intercepting DNS queries or stealing credentials via wpad. In modern CI/CD environments, it may become software supply chain attacks.

The CI/CD automation chain

Modern software development follows this pattern:

1. Developer commits code to GitLab
2. GitLab sends webhook to Bamboo CI (to trigger build)
3. Bamboo CI checks out code and runs build
4. Bamboo CI retrieves code dependencies from JFrog Artifactory
5. JFrog Artifactory serves packages (npm, nuget, etc.)
6. Bamboo CI compiles the code into deployable artifacts
7. Bamboo CI deploys the artifacts based on the YAML deployment configs
8. Artifacts deployed to PROD if QA works as intended

The problem: Steps 2, 4, and 5 were all hitting domains we controlled.

The diagram below illustrates how domain collision inserted us into this CI/CD pipeline. Notice the red-highlighted path, this is where artifactory.absorb.ad queries gave us the ability to serve malicious packages directly into their build process:

Package manager exploitation

When we sinkholed artifactory.absorb.ad, we started receiving package manager queries:

GET /artifactory/api/nuget/v3/nuget/FindPackagesById()?id='Absorb.Common.Utilities'&semVerLevel=2.0.0

We recorded 1,585 unique NuGet packages requested. These weren't just public packages being mirrored, names like Absorb.Common.Utilities, Absorb.Core.Logging, and Absorb.Infrastructure.* were clearly proprietary internal libraries.

The canary experiment: proof of exploitation

Simply seeing package requests isn't enough, we needed to prove we could influence what was being built. Referring back to the CI/CD flow diagram above, steps 4-5 represent the moment where our controlled artifactory.absorb.addomain could serve malicious responses. But we couldn't actually serve malicious packages (this was vulnerability research, not authorized penetration testing). So we designed a test…

When a NuGet client (like a build system) wants to download packages, it first requests a service index, a JSON metadata file that tells it where to find various package resources. This index contains URLs for different operations:

• /flatcontainer/ - The package download endpoint where actual .nupkg files are retrieved
• /registration/ - The package metadata endpoint for querying package information, versions, and dependencies

The client trusts this index and uses these URLs for all subsequent package operations. Here's what a legitimate service index looks like:

Our test was simple: modify the service index URLs slightly, then see if build systems requested packages using our modified URLs. If they did, it would prove they parsed and trusted our malicious index.

This was no longer a theoretical risk. This was 99,351 opportunities to inject malicious code into the software supply chain.

Absorb comment: While the canary methodology demonstrates that NuGet clients parsed and followed the malicious service index, translating this into production impact would require crossing multiple control boundaries: authenticated access to internal feeds, environment segmentation between QA and production, and release promotion gates. Our investigation found no evidence these boundaries could be bypassed.

Could this attack be detected?

Detecting malicious packages served through our controlled artifactory.absorb.ad domain would be extremely difficult, if not impossible, with standard security controls:

• The package appears to be coming from the "internal" trusted Artifactory server
• SSL certificates validate (since we own the public domain, we can obtain valid certificates from public CAs)
• Build logs show "success"
• Package names and versions match exactly what was requested
• Package hash verification passes (since we control the service index that provides package metadata, we also control the hash values that clients use for verification).
• No warnings, no errors, no anomalies in standard monitoring

Unlike traditional supply chain attacks that target public repositories (triggering security alerts, repository trust warnings, or package verification failures), domain collision attacks exploit infrastructure that organizations have already whitelisted and trust implicitly. Standard security controls won't flag packages from "internal" sources.

Absorb comment: While this class of issue may evade traditional detection signals, layered controls (build-agent egress restrictions, environment segmentation, access controls on artifact promotion, and authentication on package sources) can limit impact. In response, we tightened DNS/egress controls and enabled always-on VPN.

Beyond package injection: Authentication traffic

While analyzing the traffic patterns, we discovered that the domain collision wasn't just affecting package manager queries. Build systems and developers were actively authenticating to services on the domains we controlled, sending credentials and tokens that we passively captured. Between July 8, 2025 and January 4, 2026, we observed:

JWT Token Collection

We captured 10,152 unique JSON Web Tokens (JWTs) from various services attempting to authenticate with systems on the domains we controlled:

• 10,090 tokens issued by https://myabsorb.com/
• 20 tokens from Communities Integration Service
• 10 tokens from Recommendations Microservice
• 6 tokens from Artifactory (JFrog) - build tools authenticating for package repository access
• 2 tokens from BambooHR integration service
• 1 token from AWS Cognito

Absorb comment: The observed authentication traffic was investigated as part of our internal review and penetration testing. We maintain that captured credentials and tokens don't automatically establish actionable access, as utility depends on network segmentation, token validation controls, environment isolation, and promotion gates. Our testing concluded our controls prevented escalation to production.

Infrastructure Configuration Exposure

We received 171 complete Bamboo CI/CD specifications automatically uploaded to the domain bamboo.absorb.ad . These disclosed operational blueprints for AbsorbLMS's deployment pipelines.

• 24 deployment configurations, some with explicit descriptions:
Copy

- description: Starts EC2 Image Builder Pipeline which bakes AMI for UsProduction
- description: Performs Major LMS Release (myabsorb.com)
- description: AWS US-East (myabsorb.com / use1-prd-dms-01.absorb.ad)
- description: AWS EU-West (myabsorb.eu / euw1-prd-app-01.absorb.ad)

• 24 deployment permission specifications
• 123 environment permission specifications

While many sensitive values (like database passwords and AWS secret keys) were properly stored as Bamboo variables rather than hardcoded, we found notable exceptions: the AWS Cognito OAuth client secrets for “Content Partner” platforms were hardcoded as literal values in the YAML files for production environments across all four global regions (US, CA, AU, EU)

The response disconnect: "It's just QA"

After we clarified this wasn't a bug bounty submission and detailed the risks, AbsorbLMS's response focused on environment scoping and risk classification:

"[We] confirmed that the data in question was limited to a QA testing environment, with no exposure of client data, production systems, or other sensitive information, making it a low-risk scenario overall. To address it fully, we've now enforced always-on VPN for all employees."

Reality check

Absorb comment: We maintain the affected systems were QA-only using dummy/test data. QA pipelines commonly reference production-like naming conventions and build production code without having privileges or network access to modify production systems. Our commissioned penetration test could not pivot from QA to production or introduce malicious code into production releases.

Absorb comment: Always-on VPN was implemented to route traffic through protected network controls. Continued traffic post-implementation can reflect cached configurations, automated retries, and systems not in scope. Our risk assessment was based on segmentation and access controls, not VPN alone.

Absorb comment: Our "low risk" determination was based on: QA scope with test data, environment segmentation preventing QA-to-production pivots, no evidence of successful compromise, and no verified exposure of client data or production systems. We acknowledge the logs demonstrate request volume and breadth, but maintain this doesn't prove an external party could traverse our internal trust boundaries to alter production deliverables.

The CNAME Chain: Production Impact

We also discovered that bitbucket.absorblms.com was configured as a CNAME pointing to bitbucket.absorb.ad (a domain we controlled)

This could have concrete security implications, for example, cookies scoped to the parent domain .absorblms.com would be sent to the subdomain we controlled. Additionally, this subdomain could be weaponized for highly convincing phishing and social engineering attacks against customers and/or employees.

Absorb comment: CNAME dependencies don't automatically grant production control. Actual impact depends on whether the hostname routes end-user traffic externally (vs internal-only resolution), controls at higher layers (CDN/WAF, certificate validation, authentication), and whether the dependency serves critical application traffic versus auxiliary services.

The bigger picture

This vulnerability pattern isn't unique to AbsorbLMS. During our broader research, we've identified similar issues affecting:

• Major European cities
• U.S. law enforcement agencies
• Critical infrastructure companies
• Fortune 500 enterprises

The contributing factors are systemic:

Current status: unresolved risk

Despite repeated attempts to articulate the technical risks and underlying mechanics of this exposure, we were unable to reach alignment on the necessity of taking ownership of the affected domains as a mitigation step.

Our objective throughout this process was never financial. As with many other internal domains registered during the course of this research, our intent was to transfer the domains back to the affected organization at no cost, once appropriate technical ownership and remediation were in place. The offer of a bug bounty payout, which we declined, was not the obstacle. The challenge was the absence of collaboration with AbsorbLMS's technical team and a shared understanding of the risk posed by publicly routable internal namespaces.

This highlights a broader issue in vulnerability disclosure: organizations must be willing to trust empirical evidence over architectural assumptions. Systems behave as they are actually configured, not as we intend them to be. When researchers present logs, traffic captures, and measurable indicators of exposure, the response should prioritize investigating "why is this happening?" over explaining "why this shouldn't be possible.”

We document this case not to assign blame, but to emphasize the importance of treating researcher-provided evidence as a starting point for investigation rather than a claim to be refuted.

Unfortunately, we cannot maintain defensive registration indefinitely, so as of January 4, 2026, both absorb.ad and blatantmedia.ad expired and entered the registrar grace period. This outcome is unsatisfying, not because the vulnerability went unacknowledged, but because an opportunity to fully eliminate a systemic risk was missed.

Update (January 2026): Following our request for comment and the domain expiration on January 4, 2026, AbsorbLMS requested we renew and transfer the domains back to them. We agreed immediately.

On January 15, 2026, we restored both absorb.ad and blatantmedia.ad from the registrar's grace period at our own expense and completed the transfer process. The domains are now under Absorb's control, eliminating any risk of malicious third-party acquisition.

This outcome represents what we sought from the beginning: cooperative transfer of the domains to their rightful owner, conducted outside of bug bounty terms that were never agreed to for this research.

Closing Remarks

This work was vulnerability research, not authorized penetration testing. Our analysis is based on observable conditions and how a real adversary could reasonably attempt to exploit them.

Absorb's assessment appears to rely on assumptions about how their architecture and security controls are intended to function. We were never in a position to independently validate those assumptions without authorization.

Absorb noted that they commissioned an independent penetration test. However, without visibility into its scope, methodology, or findings, we cannot determine whether it evaluated the specific attack primitives we documented (e.g., 99,351 package installation attempts, canary service index acceptance, and credential and token exposure). These are precisely the kinds of conditions that require hands-on, adversarial validation to properly assess impact.

As part of the resolution, we requested inclusion in Absorb’s next penetration testing RFP. That would provide an opportunity to validate, through authorized testing, the controls and segmentation boundaries described in their response.

Key Takeaways

For Organizations

For Security Researchers