Use this hub to move from a threat, control gap, vendor claim, or procurement question to the evidence needed for a defensible next step.
Dated research is treated as dated research. Current operational decisions should be checked against the linked primary sources and the publication date of any Zeph Tech briefing before action is taken.
The strongest security review begins with the decision you need to make, not with a pile of controls or a vendor feature list.
Threat or incident context
Use dated briefings for context, then verify exploitable-vulnerability, advisory, and remediation status against the current primary source before making an operational call.
Turn scanner findings into a risk-ranked operating queue using asset ownership, active exploitation, exposure, exceptions, verified remediation, and meaningful metrics.
Apply HHS's current 10 essential and 10 enhanced voluntary Healthcare and Public Health cybersecurity goals with evidence that accounts for clinical resilience and patient-safety dependencies.
Choose between Microsoft-native impact-aware remediation, CIS benchmark conformance scanning, and CISA SCuBA assessment without treating one score as a complete security program.
Use the free certification-prep tracks for repeat practice and weak-domain review, then move into the deeper operational guides when a concept needs implementation context.
Carry security requirements into scoring, migration, acceptance, continuity, and exit planning instead of treating security as a one-time questionnaire.
Twenty current briefings, organized around the decisions defenders actually need to make.
The September collection connects active exploitation, privileged management planes, cloud identity compromise, AI-agent prompt injection, CI/CD risk, DNS availability, virtualization and endpoint side channels. Start with the curated priority model, then open the underlying source-backed briefings for the affected technology in your environment.
New research published after the curated threat-desk collection.
These newer briefings extend the September desk without rewriting the dated twenty-briefing collection. Use the primary sources inside each page to verify current vendor guidance before acting.
Citrix NetScaler active exploitation
Respond to CVE-2026-88771 and CVE-2026-88772 as both a remediation and compromise-assessment problem for exposed ADC and Gateway systems.
See how GitHub Security Lab structured reusable AI taskflows that have found and reported 24 Android vulnerabilities, and how to validate agent-generated findings.
Understand the new local execution boundary for agent-invoked tools, including filesystem, network and credential restrictions and the limits of the preview.
Security questions that connect to the rest of the decision
These tools are deliberately product-neutral and ad-free. They are designed to leave a reviewable trail from requirements through implementation and exit.
Incident response plan template
Define declaration criteria, decision authority, secure contacts, severity, evidence, suppliers, communications, recovery gates, playbooks, and exercise follow-through in one editable plan.
Fifty evidence-first questions across governance, identity, application security, vulnerability management, data protection, monitoring, incident response, resilience, third parties, and assurance.
Define the operating problem, users, constraints, dependencies, evidence requirements, and buyer questions before a product demonstration starts shaping the requirements.
Test whether the organization can recover service, preserve records, retrieve data, transfer knowledge, and exit the relationship without avoidable lock-in.
Briefings preserve the context available at publication. For incidents, exploited vulnerabilities, deadlines, product status, and regulatory requirements, re-check the current primary source before relying on an older article.
Cybersecurity · · 6 min read
GitHub Security Lab Finds 24 Android Vulnerabilities with Open Source AI Taskflows
GitHub Security Lab says targeted open-source AI taskflows helped researchers find and report 24 Android vulnerabilities. The useful lesson for application-security teams is not that an agent replaces expert review, but that repeatable threat-model prompts can scale entry-point analysis, variant hunting, and review coverage.
Coverage note: This Zeph Tech briefing was published on September 29, 2026 and covers GitHub Security Lab research published on . The underlying research and tooling can change, so teams should confirm current repository instructions before integrating it into production security workflows.
AI-assisted code review is becoming more useful when the model is not asked to “find bugs” in the abstract, but instead receives a repeatable security workflow that defines entry points, attack assumptions, vulnerability classes, evidence requirements, and validation steps. GitHub Security Lab’s latest Android work is a practical example of that shift. The team reports that targeted taskflows built on its open-source Taskflow Agent have found and reported 24 Android vulnerabilities so far, including flaws involving exported components and attacker-controlled intent data.
What GitHub Security Lab published
GitHub Security Lab described Android-specific audit taskflows that first identify mobile entry points and then classify those components against vulnerability patterns relevant to Android. The research emphasizes exported activities, intents, broadcasts, cross-component trust and other mobile-specific boundaries that a general code-review prompt can overlook. The taskflows break a broad audit into smaller stages so the model can preserve a threat model and revisit likely attack paths across multiple runs.
The published example involving OsmAnd illustrates why this structure matters. An exported Android activity accepted intent extras that were expected to originate from a more trusted internal path. Because an external application could also launch the exported activity and supply its own extras, the trust assumption around those parameters became security-relevant. The lesson is broader than one app: when a component is externally reachable, every field on the incoming message should be treated according to the actual caller boundary rather than the developer’s intended call path.
Why the finding matters for application-security programs
The headline number is useful, but the stronger signal is methodological. Security teams already know that large codebases contain more entry points than a reviewer can inspect manually on every release. Encoding an audit strategy as a reusable taskflow creates a way to apply the same questions across repositories, repeat the review after material changes, and preserve a record of what the agent was asked to investigate. That can improve consistency without pretending that model output is proof of exploitability.
The approach also shows why AI security review should be paired with deterministic tooling. GitHub’s earlier Taskflow Agent announcement describes a framework that can call existing security tools, including CodeQL through tool interfaces, while using natural-language tasks to coordinate the investigation. Static analysis, repository search, build tooling and controlled execution can produce evidence that is stronger than an unsupported model assertion. The model becomes an orchestration and hypothesis engine; evidence still has to establish reachability, attacker control and impact.
Priority actions for teams building Android applications
Start with a real inventory of exported activities, services, receivers, content providers, deep links and other externally reachable surfaces. For each entry point, document who can invoke it, which parameters can be controlled, what privileges the receiving component possesses, and whether the code assumes the caller is trusted. Review explicit and implicit intents separately, because routing and caller identity assumptions can differ. Treat extras, URIs, clip data and nested intents as untrusted whenever an external caller can influence them.
Add targeted variant analysis after every confirmed issue. If one exported component trusts a flag that was supposed to be set only by an internal service, search for the same pattern across related components rather than fixing one line and closing the ticket. A taskflow can make that search repeatable, but a human reviewer should still decide whether the dataflow is reachable and whether a proposed proof of concept remains inside the organization’s authorized test environment.
Run agentic review in an isolated environment with narrowly scoped credentials. GitHub Security Lab recommends Codespaces for its framework in part because it offers a sandboxed execution environment. Repositories may contain build scripts, package hooks, test harnesses or generated files that execute code during analysis. A security agent that can invoke tools should not automatically inherit broad workstation credentials, unrelated filesystem access or production secrets.
Validation and evidence requirements
Do not treat an AI-generated “vulnerable” label as a finding until the team can show the boundary that is crossed. A defensible record should identify the externally reachable component or input source, the attacker-controlled data, the sensitive sink or privileged behavior, the required preconditions, the affected versions, and a safe reproduction in an owned test environment. If the result depends on Android version, manifest configuration, permission state or another application, record those dependencies explicitly.
Track false positives and false negatives as part of the evaluation. Run the taskflow against repositories with previously fixed vulnerabilities and known-safe patterns, then compare whether the workflow rediscoveries match the expected result. A security automation system that generates hundreds of plausible statements but rarely survives manual validation can consume more analyst time than it saves. Coverage quality, confirmation rate and time-to-triage are better measures than raw alert volume.
How to operationalize AI-assisted review without creating a new risk
Define approved models, repositories and data-handling boundaries before letting an agent inspect sensitive source. Keep credentials short-lived and scoped to the repository or API the workflow actually needs. Record the taskflow version, model, important prompts, tool permissions and resulting evidence so a later reviewer can understand why the system reached its conclusion. For regulated or high-assurance code, preserve the human approval gate for report submission and production remediation.
Use a two-stage workflow: broad discovery followed by focused verification. Discovery can enumerate exported components, suspicious dataflows and related variants. Verification should narrow to a small number of hypotheses and use deterministic code tracing, instrumentation or a controlled proof of concept. This reduces the risk that model confidence is mistaken for technical certainty and produces cleaner findings for engineering teams.
Longer-term security lesson
The interesting change is not simply that an AI model can read Android code. The change is that expert review knowledge can be packaged into reusable, inspectable workflows. Mature teams can treat those workflows like other security tooling: version them, test them, measure them, restrict their permissions, and improve them when a missed issue reveals a gap in the threat model. That is a more durable pattern than relying on one large prompt or one analyst’s memory.
Questions teams should be able to answer
Does this mean AI agents can replace mobile penetration testing?
No. The published work demonstrates useful automated discovery, but the output still needs validation, impact analysis and safe reproduction. Runtime behavior, authorization context, device state and exploitability often require human-led testing.
What should we audit first?
Prioritize exported components and other inputs reachable by an untrusted application, browser or external URI. Then trace attacker-controlled values into privileged actions, file operations, WebView bridges, credentials, settings changes and cross-app data access.
What is the strongest adoption metric?
Measure confirmed findings per analyst hour, rediscovery of known test cases, false-positive rate, time from hypothesis to evidence, and the percentage of critical entry points actually covered. Avoid using token volume or raw agent alerts as a security outcome.
Related Zeph Tech guidance
Use the Vulnerability Management Program guide to turn confirmed findings into controlled remediation, the cybersecurity risk register to assign ownership and residual risk, and the Cybersecurity hub for broader defensive guidance. Teams introducing AI into security testing should also document the agent’s permissions and evidence requirements as part of the control design.
Citrix NetScaler CVE-2026-88771 and CVE-2026-88772: Active Exploitation Response Guide
Citrix disclosed eight NetScaler ADC and Gateway vulnerabilities on September 27, 2026 and says exploits of CVE-2026-88771 and CVE-2026-88772 have been observed on unmitigated deployments. Internet-facing gateway owners should prioritize fixed builds, exposure review, compromise assessment, and evidence-based recovery.
Coverage note: This Zeph Tech briefing was published on September 29, 2026 and covers Citrix’s NetScaler security bulletin. This is time-sensitive vulnerability guidance. Administrators should use the vendor bulletin as the source of truth for affected and fixed versions because build guidance can change.
Citrix has published a security bulletin covering eight vulnerabilities in customer-managed NetScaler ADC and NetScaler Gateway. Two issues deserve immediate incident-response attention: CVE-2026-88771, an improper-input-validation flaw that can allow an unauthenticated attacker to execute arbitrary commands, and CVE-2026-88772, a memory-overflow issue that can lead to remote code execution or denial of service when DTLS is enabled. Citrix states that exploitation of both vulnerabilities has been observed on unmitigated deployments.
What Citrix says is affected
Citrix’s bulletin identifies supported NetScaler 14.1 and 13.1 branches below specific fixed builds, including FIPS and NDcPP variants, as affected. CVE-2026-88771 applies to NetScaler ADC and Gateway deployments without an additional feature prerequisite. CVE-2026-88772 requires DTLS, which Citrix notes is enabled by default on VPN virtual servers. Secure Private Access Hybrid deployments using NetScaler instances also require attention, while Citrix-managed cloud services are updated by Cloud Software Group.
The vendor recommends upgrading affected customer-managed systems to the applicable fixed release, including 14.1-73.37 or later and 13.1-64.23 or later for the standard supported branches, with corresponding fixed builds for FIPS and NDcPP editions. Administrators should not reduce the response to copying a version number from a third-party article. Confirm the exact edition, appliance role and current vendor guidance before maintenance begins.
Why this is an incident-response problem, not only a patch ticket
NetScaler Gateway commonly sits at a high-trust network boundary. It can terminate remote-access sessions, broker authentication, front internal applications and process traffic before it reaches protected services. When an unauthenticated command-execution flaw is actively exploited on that boundary, installing a fixed build prevents the same vulnerability from being used again but does not establish whether an attacker already executed commands before the upgrade.
That distinction matters for evidence preservation. Teams should record the version and configuration that were present during the exposure window, retain relevant appliance and upstream logs, capture available indicators before wiping or rebuilding, and correlate gateway activity with identity-provider, VPN, endpoint and internal service telemetry. If a compromise is established or strongly suspected, credential rotation and trust re-establishment should follow the organization’s incident-response process rather than a generic password-reset checklist.
Priority response sequence
First, identify every customer-managed NetScaler ADC and Gateway instance, including disaster-recovery appliances, test environments exposed to the internet, appliances managed by service providers, and NetScaler instances embedded in hybrid access designs. Determine the exact software branch and whether DTLS is enabled. Do not assume an appliance is low risk merely because it is not the primary production gateway; standby systems and management interfaces can preserve the same trust relationships.
Second, reduce exposure where operationally possible and upgrade to the vendor-specified fixed build. Treat emergency network restrictions as temporary containment, not a substitute for remediation. Validate that the upgraded appliance is actually serving traffic and that a load balancer, failover pair, stale image or rollback mechanism has not returned a vulnerable node to service.
Third, perform compromise assessment proportional to the asset’s exposure and trust. Look for unexpected processes or commands, unusual configuration changes, new local accounts or persistence, anomalous outbound connections, suspicious authentication activity, unexpected files and evidence that sessions or credentials may have been accessed. The absence of one published indicator is not proof of safety, especially when exploitation preceded broad public disclosure.
Detection and verification
Use multiple evidence sources because an edge appliance can be both the attack target and part of the logging path. Preserve NetScaler audit and system logs where available, but also review firewall, DNS, proxy, identity-provider, remote-access and endpoint telemetry. Correlate events by time, source address, account and downstream resource. A suspicious command on the gateway becomes more consequential when followed by new authentication behavior or connections to internal systems.
After remediation, verify both vulnerability closure and security state. Confirm the running build against the current Citrix bulletin, verify cluster or HA peers, test expected remote-access functions, review configuration integrity, and establish that emergency containment did not silently break logging or monitoring. If an appliance was rebuilt, document which configuration and secrets were restored and why they can still be trusted.
Operational lessons for edge-device vulnerability management
Internet-facing access infrastructure should have a shorter emergency-remediation path than ordinary internal software. Maintain an inventory that includes product branch, management owner, exposure, authentication role, maintenance method, logging destination and recovery procedure. If the organization cannot answer those questions quickly during active exploitation, the inventory itself is a security control gap.
Keep recovery artifacts ready before the next emergency. Teams should know how to export supported configuration, rebuild from a trusted image, rotate dependent credentials, validate high-availability behavior and restore monitoring. A tabletop exercise that practices those steps can reduce the temptation to leave a vulnerable gateway online because the organization is uncertain how long recovery will take.
Third-party and service-provider coordination
Organizations that receive NetScaler administration through an MSP or shared infrastructure team should obtain explicit evidence of remediation rather than relying on a generic “patched” statement. Request the appliance identifiers, pre-change and post-change builds, completion time, exposure window, compromise-assessment scope and any credentials or trust material rotated. Contract ownership should not obscure the technical state of a gateway that protects the organization’s users and applications.
Where remote access is business-critical, communicate maintenance and recovery expectations to help-desk and incident teams before changes begin. Authentication failures, certificate issues or HA transitions during emergency work can look like malicious disruption. A shared timeline helps responders distinguish planned changes from suspicious activity and preserves a cleaner record for any later investigation.
Longer-term security lesson
Active exploitation at a remote-access boundary compresses the normal vulnerability-management timeline. The right response combines fast patching with incident thinking: preserve evidence, establish whether unauthorized activity occurred, verify trust after remediation and document why the organization believes the environment is safe. Closing the scanner finding is only one part of that decision.
Questions teams should be able to answer
Is CVE-2026-88771 configuration-dependent?
Citrix lists all NetScaler ADC and NetScaler Gateway deployments as meeting the precondition for this issue; no additional feature is required. Administrators should still verify their exact supported version and edition against the current bulletin.
What about CVE-2026-88772?
Citrix says the memory-overflow issue requires DTLS and notes that DTLS is enabled by default on VPN virtual servers. That makes configuration inventory important when prioritizing affected appliances.
Is upgrading enough after active exploitation?
Upgrading is essential to close the known vulnerabilities, but it does not determine whether exploitation already succeeded. Exposed organizations should pair remediation with compromise assessment and recovery decisions appropriate to the gateway’s role.
GitHub Copilot App Local Sandboxing: What the New Security Boundary Does and Does Not Protect
GitHub added per-project local sandboxing to the Copilot app in public preview. The feature can restrict agent-invoked tools from files, networks, and credentials, but it is off by default and does not apply to cloud sandbox sessions or remote hosts.
Coverage note: This Zeph Tech briefing was published on September 29, 2026 and covers GitHub’s local-sandboxing release for the GitHub Copilot app. The feature is in public preview, so organizations should recheck GitHub documentation before turning this analysis into a permanent control standard.
Agentic developer tools can run shell commands, install dependencies, call services and modify files. That power is useful, but it also expands the consequence of a mistaken instruction, a malicious repository, a compromised dependency or an agent decision that reaches beyond the intended project. GitHub’s new local sandboxing feature for the Copilot app addresses part of that risk by placing agent-invoked tools inside an operating-system sandbox with configurable limits on filesystem, network and credential access.
What GitHub released
Local sandboxing is configured per project for local repository and working-tree sessions. Project owners can allow additional read/write paths, grant read-only access to selected folders, explicitly deny folders, allow or block outbound internet and local-network access, and control whether authenticated Git or GitHub CLI credentials are available inside the sandbox. GitHub says the effective policy may be made more restrictive by enterprise-managed settings.
A particularly important design choice is fail-closed behavior. GitHub documents that if the operating system cannot enforce the requested policy, the sandboxed shell fails rather than silently running without the sandbox. That avoids a dangerous failure mode in which the user believes restrictions are active while the agent is actually executing with the full authority of the local account.
The security boundary this creates
A Git working tree separates branch state and concurrent changes; it is not a security boundary for the rest of the workstation. A command launched from a working tree can normally read other accessible files, connect to local services, reach the internet and reuse credentials available to the user. Local sandboxing adds a separate restriction layer around those capabilities, which is useful when an agent is allowed to execute commands on the developer’s behalf.
The control is most valuable when policy is deliberately narrower than the user account. A repository that only needs package-registry access does not necessarily need the entire local network. A documentation change does not necessarily need GitHub CLI credentials. A project stored next to confidential client data does not need read access to neighboring folders. Least privilege becomes a practical configuration choice rather than a general aspiration.
Important limits and defaults
GitHub’s documentation says local sandboxing is off by default. Enabling “Sandbox new sessions” changes new sessions for the project, not sessions that are already running. An active session can be changed with the /sandbox on command. Policy changes apply when a new session starts or an existing session restarts, so teams should not assume that editing a project policy retroactively changes a process that is already executing.
The feature also has explicit scope limits. It does not apply to cloud sandbox sessions or sessions on a remote host, and sandbox settings for the GitHub Copilot app are configured separately from Copilot CLI sandbox settings. GitHub also documents platform-specific behavior, including limitations around local-network enforcement on Linux for spawned processes. Security teams should test the exact operating system and workflow they intend to rely on rather than copying a generic policy.
Priority configuration for security-conscious teams
Start by enabling sandboxing on repositories where agents can execute tools, then remove capabilities that are not required by the normal workflow. Deny access to password stores, SSH material, cloud credential directories, unrelated source trees and sensitive document folders. Restrict local-network access when the project does not need databases, development services or internal APIs. Disable Git or GitHub CLI credentials in sessions that only need read-and-test behavior.
Use a separate policy for repositories that contain untrusted or externally contributed code. Package hooks, build scripts, test fixtures and generated tooling can execute commands in ways that are not obvious from a code-review prompt. A narrow sandbox reduces the blast radius if an agent follows a repository instruction that was crafted to reach outside the project. It does not make malicious code safe, but it changes what that code can touch.
Approval prompts and escape decisions
GitHub allows a tool blocked by policy to trigger a “Run outside the sandbox?” prompt when the effective policy permits that choice. This is a critical control point, not a convenience dialog. Teams should define when an exception is acceptable, what evidence the developer should review, and which operations must never be approved outside the sandbox. Enterprise owners can prevent users from running tools outside the sandbox, which may be appropriate for higher-risk environments.
A good policy treats escape requests as security-relevant events. If agents frequently require exceptions, the team should decide whether the policy is incorrectly designed or the workflow itself has excessive privilege requirements. Repeatedly clicking through prompts defeats the purpose of the boundary and trains users to authorize commands they have not evaluated.
Verification and monitoring
Test the sandbox with harmless negative cases before relying on it. Confirm that a denied folder cannot be read, blocked network destinations cannot be reached, disabled credentials are not usable and the shell fails when a requested policy cannot be enforced. Repeat those tests after operating-system upgrades or major Copilot app changes because the feature is still in preview.
Record which projects require sandboxing, which capabilities are allowed, who can change the policy and how exceptions are handled. For enterprise environments, combine the sandbox with endpoint monitoring, secret scanning, protected branches and least-privilege repository permissions. The sandbox limits a local execution path; it does not replace code review, identity controls or safe dependency management.
Longer-term security lesson
Agentic development changes the meaning of “developer tooling.” An assistant that can invoke tools is closer to an automation principal operating under the user’s authority. Security architecture should therefore focus on capabilities: which files it can read, which systems it can reach, which credentials it can use and which actions require explicit human approval. Sandboxing makes those capabilities visible and enforceable.
Questions teams should be able to answer
Is local sandboxing enabled automatically?
No. GitHub documents the feature as off by default for local Copilot app sessions. Projects must enable it for new sessions or users can turn it on for an active session with the documented slash command.
Does a Git working tree provide the same protection?
No. A working tree separates Git state for concurrent work, but GitHub explicitly notes that it does not restrict what commands can access elsewhere on the machine. The operating-system sandbox provides the additional access boundary.
Does this cover every Copilot execution environment?
No. GitHub says local sandboxing applies to local repository and working-tree sessions, not cloud sandbox sessions or remote-host sessions, and the app’s settings are separate from Copilot CLI sandbox settings.
GitHub has published a staged SSH security transition: new RSA keys uploaded after October 14, 2026 must be at least 3072 bits, SHA-1 RSA signatures and an older Diffie-Hellman exchange are scheduled for removal, and GitHub is adding ML-KEM hybrid post-quantum key exchange support.
Coverage note: This Zeph Tech briefing was published on September 29, 2026 and covers GitHub’s SSH security announcement. Several dates are still in the future. Administrators should verify GitHub’s current changelog before a migration because schedules can change.
GitHub is tightening the cryptographic baseline for SSH connections and adding a hybrid post-quantum key-exchange option. The changes matter most to organizations with older Git clients, automation libraries, build servers or long-lived SSH configurations. Teams using HTTPS Git remotes are outside the primary impact described by GitHub, but organizations with SSH-heavy CI/CD should inventory client versions now rather than discovering incompatibility during a brownout.
What is changing
GitHub says it will remove the ability to use RSA keys with the SHA-1 ssh-rsa signature type, remove the diffie-hellman-group-exchange-sha256 key-exchange mechanism, and require newly uploaded RSA SSH keys to be at least 3072 bits beginning October 14, 2026. GitHub is also adding support for the hybrid post-quantum key-exchange method mlkem768x25519-sha256 on github.com and GitHub Enterprise Cloud with Data Residency, except for the U.S. region as described in the announcement.
The distinction between an RSA key and the ssh-rsa signature algorithm is important. GitHub explains that an existing RSA key does not automatically need to be replaced if the client can use RSA with SHA-2 signatures such as rsa-sha2-256 or rsa-sha2-512. The migration problem is therefore often an outdated SSH implementation or configuration, not simply the presence of an RSA public key.
The published schedule
GitHub’s current schedule sets October 14, 2026 for the new minimum size on newly uploaded RSA keys and for enabling the ML-KEM hybrid key exchange in the listed environments. Brownouts for the deprecated SHA-1 RSA signature type and older Diffie-Hellman exchange are scheduled for November 4 and December 9, 2026. Final removal is scheduled for January 13, 2027. GitHub Enterprise Server receives the changes in later product versions identified in the announcement.
Brownouts are operationally useful because they surface hidden dependencies before permanent removal. Organizations should treat them as planned validation windows, not unexpected outages. A build server that fails only during a brownout is evidence of an obsolete SSH path that needs remediation before the final date.
How to inventory exposure
Search CI/CD systems, developer workstations, deployment automation, artifact builders, source mirrors and third-party integrations for Git remotes beginning with git@github.com: or ssh://. Record the actual SSH implementation and version behind each workflow. The visible application name is not enough because Java libraries, embedded appliances and build tools may carry their own SSH stack independently of the operating system’s OpenSSH client.
Test the negotiated algorithms rather than inferring them from the key file name. An RSA public key labeled ssh-rsa can still be used with a SHA-2 signature when the client and server negotiate it. Capture verbose SSH negotiation in a controlled test or use the relevant client diagnostics to confirm whether the workflow depends on SHA-1 or the retiring Diffie-Hellman exchange.
Migration priorities
Upgrade old SSH clients and libraries first. GitHub’s announcement lists baseline versions for several common implementations, including OpenSSH, JSch, TeamCity, Go SSH, libssh2 and PuTTY, that support RSA with SHA-2 robustly in default configurations. Use the current vendor documentation for each product rather than treating those versions as universal security-support guarantees.
For new developer keys, GitHub recommends Ed25519 when possible. If compatibility requires RSA, new uploads after the scheduled October date must meet the 3072-bit minimum. Do not regenerate every existing RSA key reflexively: determine whether the current client negotiates SHA-2 and whether key rotation is otherwise warranted by age, ownership, storage or exposure. Unnecessary emergency key churn can create its own operational risk.
Post-quantum key exchange without hype
The mlkem768x25519-sha256 method combines ML-KEM with X25519 in a hybrid construction. GitHub says compatible SSH clients should use the new method when configured to prefer it, while older clients can fall back to another supported exchange. The practical near-term value is cryptographic agility: organizations can begin using a quantum-resistant component without making SSH connectivity depend exclusively on a new algorithm.
Post-quantum support does not eliminate the ordinary causes of SSH compromise. Stolen private keys, excessive repository permissions, exposed CI secrets, unreviewed deploy keys and compromised developer endpoints remain immediate risks. The new key exchange should be treated as one layer in a broader identity and access-control program rather than a substitute for key hygiene.
Validation plan before GitHub’s brownouts
Create a representative test matrix covering developer clients, CI runners, build servers, automation libraries and service accounts. For each, test clone, fetch, push and any signed or automated operation that uses SSH. Capture client versions and negotiated algorithms, then remediate unsupported paths. Re-run the matrix during the published brownout windows if operationally feasible so the organization gets evidence before final retirement.
Make rollback planning explicit. If upgrading an embedded library breaks a critical release path, know whether the workflow can temporarily use HTTPS with a supported authentication method while the SSH dependency is repaired. A fallback should be secure and tested in advance; disabling host verification or re-enabling weak algorithms under deadline pressure is not an acceptable recovery strategy.
CI/CD and machine-account considerations
Machine users deserve separate testing from developer laptops because they often run older runtimes for years and fail outside normal business hours. Inventory self-hosted runners, release appliances, dependency mirrors, infrastructure-as-code systems and vendor integrations that authenticate to GitHub over SSH. Record an accountable owner and a tested upgrade path for every dependency that cannot meet the new baseline.
Use the transition to review key ownership as well as algorithms. Shared private keys, deploy keys with broad repository access and credentials copied between build systems create risks that stronger cryptography does not solve. Where possible, give automation a narrowly scoped identity, store private material in a managed secret system, rotate abandoned credentials and remove keys whose owner or purpose cannot be established.
Longer-term security lesson
Cryptographic deprecation is an inventory problem as much as a mathematics problem. Modern services can remove weak algorithms only when customers know which clients still depend on them. Maintaining an accurate list of protocols, libraries, keys and automation owners makes future deprecations routine instead of disruptive. The same discipline will matter as post-quantum transitions expand beyond a single Git hosting service.
Questions teams should be able to answer
Do all existing RSA keys have to be replaced?
No. GitHub says existing RSA keys can continue when the SSH client supports RSA with SHA-2 signatures. The deprecated item is the SHA-1 ssh-rsa signature type, not every RSA key.
Who is most likely to break?
Older SSH libraries, long-lived build systems and embedded integrations deserve the earliest testing. Modern OpenSSH clients generally negotiate stronger algorithms automatically, but organizations should verify their actual environment.
Does ML-KEM require every user to upgrade immediately?
GitHub says older clients can fall back to an older supported key-exchange algorithm. The immediate operational deadline is more likely to come from deprecated algorithms than from failure to adopt the new hybrid exchange.
SharePoint CVE-2026-65660 Enters the Exploited-Vulnerability Conversation: How to Respond
CVE-2026-65660 is a high-severity SharePoint Server vulnerability associated with active exploitation reporting and CISA KEV tracking. Organizations running on-premises SharePoint should combine patching with compromise assessment and credential review.
Archive coverage note: This Zeph Tech briefing was published on September 27, 2026 and documents a security development from . The historical date in the URL identifies the covered event; it is not a claim that Zeph Tech originally published the page on that date.
On-premises collaboration platforms often combine internet exposure, authentication, document access and privileged service accounts. That mix makes SharePoint vulnerabilities important even for organizations that otherwise operate heavily in cloud services.
What happened
Microsoft tracks CVE-2026-65660 in the Security Update Guide, and public vulnerability records identify it as a SharePoint Server vulnerability with high impact. By late September, the issue had been associated with active exploitation evidence and KEV tracking, increasing the urgency for defenders.
The vulnerability affects Microsoft SharePoint Server rather than SharePoint Online-only environments.
Public CVE records list a high-severity network attack path with low attack complexity and low privileges required.
CISA KEV status means defenders should treat the flaw as demonstrated exploitation rather than theoretical exposure.
Microsoft's September SharePoint security updates also addressed multiple additional SharePoint and Office-related weaknesses.
Why defenders should care
SharePoint commonly stores sensitive documents and integrates with Active Directory, service accounts and internal applications. An exploited server can become both a data-access problem and a lateral-movement platform.
Attackers may use a vulnerable SharePoint server to access sensitive collaboration content.
Service-account permissions can expand the effect beyond the web application itself.
Public-facing collaboration systems are easy to discover and may remain reachable long after patch release.
Post-exploitation persistence can survive a patch if defenders do not perform incident triage.
Priority response
Organizations affected by this development should treat remediation as an operational workflow rather than a single patching checkbox. Confirm exposure, reduce reachable attack surface, apply the vendor-supported fix or control, and then verify whether compromise may have occurred before remediation.
Identify every on-premises SharePoint farm and verify exact patch level against Microsoft's Security Update Guide.
Prioritize internet-facing or externally published SharePoint services.
Apply the applicable security updates using Microsoft's documented installation requirements.
Review IIS, SharePoint, Windows and identity logs for abnormal requests, account use, process execution and persistence.
Check privileged service accounts and application credentials for unusual use during the exposure period.
Validate backups and recovery procedures for both SharePoint content and farm configuration.
Detection and verification
Search for abnormal web requests, unexpected child processes under IIS or SharePoint service contexts, suspicious PowerShell, newly created scheduled tasks or services, unusual access to configuration databases, and logons by SharePoint-related service accounts from unexpected hosts.
Preserve relevant logs before disruptive remediation when practical, compare current configuration with a known-good baseline, and document both the technical fix and the evidence used to determine whether follow-on incident response is required. Where a vulnerability is known to be exploited, patch status alone does not answer whether the system was already compromised.
Longer-term security lesson
Collaboration servers should have explicit owners, reliable maintenance windows and monitored external exposure. A vulnerability-management program that cannot quickly answer 'which farms are public, who owns them and what credentials they hold?' will lose time when exploitation becomes active.
For program owners, this event is also a useful test of asset inventory, ownership, vulnerability prioritization, evidence retention, and communication. Teams should be able to identify affected systems quickly, name an accountable owner, record the mitigation decision, and prove that the control change reached production. Those capabilities are often more important than any one scanner score.
Questions teams should be able to answer
Does this concern SharePoint Online?
The vulnerability is associated with SharePoint Server. Cloud service exposure should be evaluated separately using Microsoft's service guidance.
What does KEV status change?
It indicates evidence of exploitation in the wild and should elevate remediation and compromise-assessment priority.
Should service accounts be reviewed?
Yes. SharePoint deployments often rely on privileged or broadly trusted service identities, so suspicious use can be an important sign of lateral movement.
Treat an on-premises SharePoint farm as a multi-tier application and data platform. Identify affected web front ends, application servers, databases, search components, custom solutions and service accounts. Determine which sites and document libraries hold sensitive content and whether the exposed tier could use privileged identities elsewhere.
Preserve IIS and ULS logs, Windows event data, PowerShell activity, file changes, scheduled tasks, new services, solution deployments, farm administration actions, database access and identity-provider events. Review SharePoint service-account use from unexpected hosts because lateral movement may be more important than the original web request.
Turn remediation into an auditable control
Maintain complete farm inventory and patch ownership, reduce unnecessary public exposure, use distinct least-privilege service accounts, protect administrative access with strong MFA, and test backup and restore for both content and farm configuration. Unsupported farms should have a funded upgrade or retirement path rather than indefinite exception status.
Measure whether the control is improving instead of counting closed tickets. Useful indicators for this topic include internet-facing SharePoint endpoints; exploited-vulnerability patch latency; unsupported farms; privileged service identities; failed update attempts; age of last tested restore; and service-account logons originating outside expected farm systems. Review the measures after material architecture changes and after incidents so the program does not optimize for a stale threat model.
Keep a defensible decision record
For SharePoint, record every farm and server in scope, public exposure, exact security update level, service-account review, IIS and ULS evidence retained, sensitive content considered, and whether the team found any post-exploitation behavior requiring a broader identity or data incident. Capture who approved the final risk disposition and the date the temporary incident controls can be removed or must be reviewed again. A concise decision record prevents emergency actions from becoming undocumented permanent architecture and gives the next responder a verified starting point instead of forcing the team to reconstruct the event from tickets and memory.
Owner handoff before closure
Before closing the response to Microsoft SharePoint, the technical owner and the risk owner should agree on what evidence demonstrates completion. Record the affected inventory, final software or configuration state, temporary controls still in place, credentials or identities changed, detection coverage added, and any systems excluded from remediation with an explicit reason. Confirm that monitoring will detect recurrence and that the service owner knows which future change would invalidate the current risk decision. If the event exposed an inventory, logging, ownership or recovery gap, assign that gap as separate tracked work instead of burying it inside the original patch ticket. A short post-response review should also capture which step consumed the most time and which dependency prevented faster action. That information is operationally valuable: it lets the next incident start with a tested owner map, reliable evidence sources and a known containment path rather than repeating discovery under pressure.
A security program is easier to evaluate when each outcome has an owner, an operating cadence, and evidence that can be independently reviewed.
Govern and prioritize
Tie risk decisions to mission, assets, suppliers, obligations, tolerances, and accountable owners. Use a current target profile instead of treating a framework as a checklist.
Protect and detect
Translate target outcomes into identity, configuration, software, data, telemetry, vulnerability, and supplier controls with evidence the organization can inspect.
Respond, recover, improve
Exercise escalation, communications, containment, restoration, evidence preservation, lessons learned, and ownership of corrective actions before an incident forces the process.
These sources are intentionally external because current security decisions should be checked against the organization that publishes or maintains the authoritative material.
CISA Secure by Design — guidance for shifting security responsibility toward technology manufacturers.
Zeph Tech summarizes and connects evidence; it is not the authority that sets these standards or maintains these threat catalogs. See the editorial standards for source hierarchy, corrections, and current-vs-historical treatment.
Next step
Keep security tied to the actual decision
Use the broader resource library when the question crosses security, accessibility, migration, scoring, continuity, or procurement. Use the fit-review path when you need to discuss a concrete implementation or technology decision.
