From LDAP Signing Bypass to SVG XSS: Four Security Research Studies Worth Adding to Your Pentest Checklist

October 23–30, 2026 | RedSide Security Research Digest

Security controls do not always fail because they are missing or incorrectly configured. Sometimes, they fail because security assumptions that hold within one component break when data, authentication, or execution crosses into another.

This week's cybersecurity research highlights four examples:

• An LDAP connection verifies a signed message, but the authentication context changes during processing.
• An SVG sanitizer removes dangerous content, but browser-specific parsing and rendering behavior creates new attack opportunities.
• Cloud IAM restrictions protect management APIs, but internal runtime services expose alternative access paths.
• Repository and CI/CD security controls exist, but malicious workflows and IDE configurations introduce additional execution opportunities.

At RedSide Security, we selected four technically detailed publications covering Active Directory, web application security, cloud infrastructure, and software supply chain attacks.

Each study offers practical lessons for penetration testers, Red Team operators, application security engineers, and defenders.

1. LDAP Signing Bypass: When Reauthentication Changes the Security Context

Published: October 23, 2026
Researcher: Raj Patel, SpecterOps
Category: Active Directory / LDAP / NTLM Relay

SpecterOps published technical research examining an LDAP signing bypass involving reauthentication within an established connection.

The issue arises when an LDAP server validates a signed SASL message using the original session key but changes the associated security context while processing that message.

As a result, a subsequent LDAP operation may execute under another account's privileges, despite the message having passed signature verification.

Technical Findings

The research describes an attack chain involving:

• An existing LDAP connection using SASL authentication
• Reauthentication during an authenticated session
• Successful signature verification using the original session key
• A security-context transition during message processing
• Subsequent LDAP operations executed with a different account's privileges

The publication also provides network traffic analysis, a root-cause investigation, and a demonstration involving Resource-Based Constrained Delegation (RBCD).

According to the researcher, the LDAP variant was addressed in the October 2026 Windows security updates.

Why It Matters for Penetration Testing

LDAP signing is an important protection against certain relay attacks. However, verifying that LDAP signing is enabled does not establish that every related attack path has been eliminated.

Security assessments should consider:

• Windows security patch levels
• LDAP signing enforcement
• LDAP channel binding
• NTLM authentication exposure
• Authentication relay prerequisites
• Conditions required to obtain authentication from a target account

Practical takeaway: Security controls must be evaluated together with their implementation, patch status, and authentication-state transitions.

RedSide Security Assessment

The SpecterOps publication presents strong technical evidence through packet-level analysis and a detailed root-cause explanation.

However, exploitation requires specific prerequisites. The research does not establish that every LDAP deployment enforcing signing is vulnerable.

Original research: SpecterOps — LDAP Signing Bypass and NTLM Relay

2. SVG Sanitization Bypasses: Why Clean Files Can Still Trigger XSS

Published: October 27, 2026
Researcher: Gareth Heyes, PortSwigger
Category: Web Application Security / XSS / File Upload Security

PortSwigger researcher Gareth Heyes published Scalable Vector Grief, an investigation into weaknesses in SVG sanitization and browser rendering behavior.

According to the research, the author bypassed six of eight tested SVG sanitization libraries.

The findings demonstrate why sanitizing uploaded SVG content does not necessarily guarantee safe rendering.

Technical Findings

The research explores several attack techniques:

XML namespace confusion

Different interpretations of XML namespaces can create inconsistencies between sanitization logic and browser behavior.

SVG animation and URL manipulation

SVG animation features can influence URL-related attributes in ways that may bypass filtering assumptions.

Browser-specific rendering behavior

The research includes examples involving:

• JavaScript execution through an XSLT stylesheet referenced by a Link response header in Firefox
• Importing external file content as SVG in Safari
• Differences in parsing, resource loading, and content interpretation

These behaviors demonstrate how a file considered safe by one component may be processed differently by another.

Why It Matters for Penetration Testing

SVG upload security should be assessed throughout the complete file lifecycle:

1. File acceptance and validation
2. Sanitization and content transformation
3. Storage and retrieval
4. HTTP response headers and MIME types
5. Browser rendering and embedding

Testing should consider whether uploaded content is served from the application's primary origin, an isolated domain, or another security boundary.

An SVG file may behave differently depending on whether it is embedded as an image, loaded directly as a document, or interpreted by browser-specific features.

Practical takeaway: Successful sanitization is not equivalent to safe browser execution. Assess the entire upload-to-render pipeline.

RedSide Security Assessment

This research is particularly useful for web application penetration testing because it contains concrete examples suitable for controlled laboratory reproduction.

However, the findings should not automatically be generalized to every sanitizer version and browser configuration. The publication does not provide a complete compatibility matrix.

Original research: PortSwigger — Scalable Vector Grief

3. Google Cloud Apigee: IAM Restrictions Do Not Guarantee Runtime Isolation

Published: October 28, 2026
Researcher: Moshe Bernstein, Tenable
Category: Cloud Security / IAM / Multi-Tenant Isolation

Tenable published an advisory describing an isolation bypass between Google Cloud Apigee environments.

According to the research, a user with permission to deploy an API proxy into one environment could interact with internal services to retrieve runtime configurations belonging to other environments hosted on the same instance.

This access could expose information that the user's management API permissions would otherwise prevent them from retrieving.

Technical Findings

Potentially accessible configuration information included:

• API proxy source code
• Runtime configurations
• Proxy policies
• Sensitive environment settings

The security boundary failed because authorization enforced through the management API did not necessarily provide equivalent protection through internal runtime services.

The attack scenario required specific conditions, including proxy deployment permissions and multiple environments sharing an instance.

Why It Matters for Penetration Testing

Cloud security assessments often focus heavily on IAM policies and externally exposed APIs.

However, internal infrastructure can introduce additional access paths.

Security testing should evaluate:

• Differences between management-plane and runtime-plane authorization
• Internal services reachable from deployed workloads
• Environment isolation boundaries
• Permissions granted through proxy deployment capabilities
• Whether access restrictions are consistently enforced across interfaces

Practical takeaway: Authorization must be enforced at every relevant trust boundary, not only at the public management API.

RedSide Security Assessment

The Tenable advisory provides reproduction conditions and identifies a meaningful isolation problem.

Nevertheless, exploitation requires deployment permissions and a shared-instance environment.

The advisory classifies the issue as Low severity, despite using stronger language elsewhere in its description.

Tenable reports that Google is rolling out a fix but does not specify a completion date.

Original research: Tenable — TRA-2026-67

4. GhostAction and PolinRider: Attacks Across GitHub, CI/CD, and Developer Workstations

Published: October 27, 2026
Researcher: Gaetan Ferry, GitGuardian
Category: Software Supply Chain / GitHub Actions / Developer Security

GitGuardian published technical research examining the evolving GhostAction campaign and its overlap with PolinRider techniques.

The analysis highlights how malicious repository content can affect both automated build infrastructure and developer workstations.

Rather than relying on one execution mechanism, the reported techniques target multiple points within the software development lifecycle.

Technical Findings

The publication examines several techniques:

Malicious GitHub Actions workflows

Attackers introduce or modify workflow definitions to create opportunities for code execution within CI/CD environments.

Self-hosted runner targeting

Self-hosted GitHub Actions runners may provide access to internal infrastructure, local credentials, and development resources, depending on their configuration.

AWS OIDC session abuse attempts

The campaign included attempts to obtain AWS sessions through OpenID Connect authentication flows associated with CI/CD infrastructure.

JavaScript disguised as a font file

The researchers identified JavaScript content packaged to resemble an unrelated file type.

IDE-based execution paths

The analysis also describes scenarios involving VS Code tasks and workspace trust decisions.

These demonstrate that simply opening and working with repository content may introduce additional execution risks, depending on the developer environment and user actions.

Why It Matters for Penetration Testing

Repository security extends beyond source code review.

Security teams should evaluate the broader developer environment, including:

• GitHub Actions workflow permissions
• Pull request and workflow change controls
• Self-hosted runner isolation
• Secrets available to build processes
• AWS OIDC trust policy restrictions
• VS Code workspace configurations and tasks
• Repository file types and suspicious execution mechanisms
• Developer endpoint security

Incident response procedures should also account for compromised credentials, token revocation, runner cleanup, and developer workstation investigation.

Practical takeaway: Protecting CI/CD pipelines is necessary, but developer workstations and repository execution paths must also be included in the threat model.

RedSide Security Assessment

GitGuardian's analysis includes technical artifacts such as code examples, hashes, and commit history, making the findings useful for security investigations and detection engineering.

However, the presence of malicious files in repositories should not be interpreted as evidence that every affected repository resulted in successful compromise.

Some variants reportedly encountered execution errors or were prevented from completing their intended actions.

Original research: GitGuardian — GhostAction × PolinRider

Practical Pentest Checklist: What to Add to Your Next Assessment

These four studies highlight different attack surfaces, but they share a common theme: security controls must be tested across the boundaries where their assumptions can fail.

Key Lessons for Security Teams

1. Configuration Compliance Is Not Proof of Security

A control being enabled does not automatically guarantee that every related exploitation path has been eliminated.

Security assessments should examine real behavior, implementation details, and patch levels.

2. Trust Boundaries Deserve More Attention

Authentication context transitions, file-processing pipelines, internal cloud services, and developer tooling can all introduce inconsistencies.

Threat models should explicitly represent these boundaries and identify where one component trusts another.

3. Test Realistic Exploitation Prerequisites

Security findings should document the conditions necessary for exploitation.

That includes required permissions, environmental dependencies, authentication prerequisites, and configuration-specific behavior.

4. Distinguish Demonstrated Exploitation From Potential Exposure

A confirmed exploit against one specific configuration does not establish universal exploitability.

Likewise, discovering malicious content or insecure behavior does not automatically prove successful compromise.

Clear evidence and reproducible testing are essential for accurate risk assessment.

Conclusion

This week's research reinforces an important principle of effective penetration testing:

Security is not defined only by whether a control exists, but by whether its assumptions remain valid throughout the system.

The LDAP signing bypass demonstrates the importance of authentication-state handling. SVG sanitization research highlights the risks of inconsistent content interpretation. The Apigee advisory illustrates gaps between IAM policy and runtime access, while GhostAction shows how development infrastructure can create unexpected execution paths.

At RedSide Security, we believe the greatest value of technical research comes from translating published findings into realistic, testable scenarios.

A useful penetration test establishes the conditions under which a control works, identifies its limitations, and produces evidence supporting its conclusions.

This digest is based on research published by SpecterOps, PortSwigger, Tenable, and GitGuardian between October 23 and October 30, 2026. RedSide Security's assessments do not imply independent reproduction of every proof of concept.

Published by RedSide Security | RedSide Security Blog