Cybersecurity guide

Cybersecurity Guide for Home Users

A practical security plan for people who want to protect their accounts, money, devices, and family data without becoming cybersecurity specialists. Start with the accounts that can unlock everything else, then work outward to devices, the home network, smart products, backups, and recovery.

By Kodi A. Cochran · Substantively reviewed September 2, 2026

This guide uses current FBI, NIST, and FTC material. Product interfaces differ, so use the security and recovery controls provided by your actual account, device, router, carrier, and financial institution.

Start with the controls that prevent one mistake from becoming ten

The FBI's Internet Crime Complaint Center received 1,008,597 complaints for 2025 and reported nearly $21 billion in losses. Phishing/spoofing, extortion, and investment schemes were among the most frequently reported complaint categories. The FBI also described scammers using fake social profiles, voice cloning, altered identification documents, and convincing synthetic media to create pressure and impersonate trusted people.^{FBI 2025 Internet Crime Report release, April 2026}

Those complaint figures describe reports submitted to IC3; they are not a probability that a particular household will be victimized. The useful lesson is simpler: modern consumer security is not just antivirus. Attackers frequently try to take over trusted accounts, persuade people to authorize payments, steal recovery codes, impersonate people or organizations, and exploit devices that no longer receive security fixes.

If you only have an hour, do these things first: secure your primary email account, turn on strong multi-factor authentication or a passkey where available, stop reusing passwords, update your phones/computers/router, verify your backups, and make sure you know how to recover the accounts that matter most.

The order matters

Your primary email account is often the recovery path for banking, shopping, social media, cloud storage, and other accounts. Your phone may receive authentication prompts and recovery messages. Your password manager may hold nearly every credential. Treat those as high-value security roots.

Secure the primary email account. Use a unique credential, stronger authentication, current recovery information, and review active sessions/devices.
Secure financial and identity accounts. Banking, payment, tax, government, healthcare, carrier, and major shopping accounts deserve the same treatment.
Secure the device that authenticates you. Update it, use a strong screen lock, enable device encryption where supported, and protect the account used for device recovery.
Fix password reuse. A unique password for every password-based account prevents one breach from automatically unlocking another service.
Secure the router and connected devices. Unsupported infrastructure can undermine otherwise well-secured accounts.
Test recovery. Know how to restore important files and regain access before you are locked out or a device fails.

1. Protect your accounts and recovery paths

Use unique passwords, not password formulas

NIST's current Digital Identity Guidelines moved away from mandatory mixtures of uppercase, lowercase, numbers, and symbols. For systems that use a password as the only authentication factor, NIST SP 800-63B-4 requires verifiers to use a minimum of 15 characters, block commonly used or compromised values, and not impose other composition rules. NIST also says passwords should not be changed periodically unless there is evidence of compromise.^{NIST SP 800-63B-4}

That document governs federal digital identity implementations rather than every consumer website, but it is a useful modern benchmark. As a user, the important habits are: make passwords long, keep them unique, do not create predictable variations such as changing only a number or symbol, and replace a credential when you learn it may have been exposed.

Use a password manager when you have many accounts

A password manager can generate and store unique credentials so you do not have to memorize dozens of them. Protect the manager itself with a strong master credential and the strongest additional authentication it supports. Keep recovery information current and understand what happens if you lose the device or master credential.

Prefer stronger authentication when an account offers it

Two-factor or multi-factor authentication makes a stolen password less useful. NIST distinguishes phishing-resistant cryptographic authentication from passwords and manually entered one-time codes. WebAuthn is one example of a standard that provides phishing resistance through cryptographic binding to the legitimate site's domain.^{NIST SP 800-63B-4 authenticator requirements}

For a consumer, that generally means: use a passkey or security-key-style option when a trusted service offers one and you understand its recovery model; otherwise use an authenticator-based second factor when available. A text-message code is still useful when it is the only second factor offered, but do not share a verification code because someone calls, texts, or emails asking for it.

Protect account recovery with the same care as login

Review recovery email addresses, phone numbers, trusted devices, backup codes, and active sessions on high-value accounts. Remove devices and recovery methods you no longer control. Store recovery codes somewhere that remains accessible if your phone is lost but is not casually exposed in email or an unlocked note.

2. Treat unexpected urgency as a reason to verify

Scams arrive through email, text messages, phone calls, social media, search results, advertisements, QR codes, and compromised accounts belonging to people you know. The medium changes; the pressure pattern is often similar.

Stop before you act

Do not use a phone number, login link, payment address, or support contact supplied by an unexpected message when money or account access is at stake.
Open the organization's known app or type a known address yourself. For a person, contact them through a separate channel you already trust.
Never provide a one-time verification code, password-reset code, backup code, or remote-control access simply because someone claims to be support, your bank, law enforcement, a government agency, or a family member.
Be skeptical of instructions to move money to “protect” it, purchase gift cards or cryptocurrency, deposit a check and return part of the money, or bypass a bank's normal fraud controls.
Voice and video are no longer sufficient proof of identity by themselves. When a high-stakes request is unusual, verify it independently.

The FTC's consumer guidance recommends contacting the company through a phone number or website you know is real rather than clicking an unexpected message's link.^{FTC: Protect Your Personal Information From Hackers and Scammers}

Do not execute commands copied from a website or message unless you understand them

In June 2026 the FTC warned about fake CAPTCHA pages that instruct visitors to open a system command interface and paste/run hidden commands, resulting in malware installation. A legitimate human-verification challenge should not require you to run operating-system commands.^{FTC: How to spot a CAPTCHA scam}

3. Keep phones and computers supported, updated, and locked

Turn on automatic operating-system, browser, application, and security updates when practical. FTC consumer guidance notes that updates often contain important security fixes and recommends keeping software current.^{FTC consumer security guidance}

Use the security features already in the device

Use a non-trivial screen lock and biometric unlock if it helps you consistently keep the device locked.
Enable built-in device encryption where it is not already automatic.
Use the platform's device-location and remote-lock/wipe capability if you are comfortable with the account and privacy tradeoff.
Install applications from sources you intentionally trust and remove applications or browser extensions you no longer use.
Review sensitive permissions such as microphone, camera, accessibility, location, contacts, and full-disk/file access.
Do not disable built-in security protections just to install an application that demands it unless you understand the consequence.

If a phone, computer, or operating system no longer receives security updates, plan to replace or retire it from sensitive use. An unsupported device can remain functional while accumulating publicly known vulnerabilities.

4. Secure the home router without guessing at its interface

Do not assume every router is managed at the same private IP address or has the same feature names. Use the manufacturer's or internet provider's documented administration method for your exact model.

NIST IR 8425A defines cybersecurity outcomes for consumer-grade router products, while FTC guidance gives consumers a straightforward configuration baseline.^{NIST IR 8425A}^{FTC: How To Secure Your Home Wi-Fi Network}

Use WPA3 Personal when supported, or WPA2 Personal when WPA3 is unavailable. Do not rely on WEP or original WPA.
Change factory/default router administrator credentials and use a unique Wi-Fi password.
Enable automatic firmware/security updates when the product supports them; otherwise follow the vendor's supported update process.
Disable internet-facing remote administration unless you have a real need for it and know how it is protected.
Disable WPS and UPnP when you do not need them and your environment functions correctly without them.
Use a guest network for visitors and, where practical, untrusted or lower-assurance smart devices.
Confirm the router still receives security support. Replace it when it reaches end of security support rather than using an arbitrary age rule.

A different DNS resolver can provide privacy or filtering features, but it is not a substitute for keeping the router and endpoints secure. Choose one only after understanding who operates it, what it logs or filters, and what changes when the service is unavailable.

5. Buy and operate smart devices with the support lifecycle in mind

NIST's consumer IoT profile emphasizes capabilities across the whole product, including configuration, data protection, software updates, cybersecurity state awareness, and information about vulnerabilities and the support lifecycle.^{NIST IR 8425} NIST's April 2026 IoT guidance update also emphasizes post-market support and end-of-life communication.^{NIST IoT guidance update, April 2026}

Before buying

Look for a manufacturer that explains how long security updates are expected, how vulnerabilities are reported, whether the device supports unique credentials or modern authentication, what cloud service is required, and what happens to your data and functionality when support ends.

After setup

Replace default credentials when the device uses them and enable stronger authentication if supported.
Apply security updates and enable automatic updates when appropriate.
Disable remote access, microphones, cameras, cloud integrations, sharing, or purchasing features you do not use.
Review which household accounts can administer the device and remove former users.
Place less-trusted IoT devices on a guest or isolated network when your router provides a workable isolation feature.
Retire or isolate a security-sensitive device when its manufacturer stops security support.

6. Back up what cannot be recreated

Prioritize irreplaceable photos and videos, personal documents, tax and financial records, creative work, password/recovery material that is appropriate to back up, and any data that would cause serious harm if a phone or computer failed today.

A useful backup has independence and history

Keep more than one copy of important data and avoid making every copy depend on the same account, device, or continuously synchronized folder. Synchronization is useful for availability, but deletion, corruption, or ransomware can sometimes propagate to synchronized copies. Version history, a protected backup service, or a disconnected/local copy can provide a recovery point that ordinary sync does not.

Test recovery periodically. Open restored files, not just the backup application. For encrypted backups, make sure you can recover the encryption key or account. For cloud backups, understand how account recovery works if your phone is lost at the same time.

7. If an account is taken over

The FTC recommends using the provider's recovery process, securing the device first when malware may be involved, then changing the password, signing out other sessions, enabling two-factor authentication, and reviewing recovery information after regaining access.^{FTC: How To Recover Your Hacked Email or Social Media Account}

Use a trusted device and the service provider's official recovery path.
If you still have access, change the credential to a new unique one and remove unknown sessions/devices.
Review MFA methods, recovery email/phone details, app passwords, connected applications, delegated access, and email forwarding/filter rules.
Check other accounts where the same password was reused and replace it there immediately.
If the compromised account is email, assume password resets or messages for other services may have been visible and review high-value accounts.
Warn contacts if the attacker used your account to send scams.

8. If you think malware or remote-control software was installed

If a scammer gained remote access or you ran an unknown command, disconnecting the affected device from the network can stop ongoing remote access while you assess it. Use another trusted device for urgent password changes if you believe credentials may have been captured.

FTC guidance for a computer or phone exposed to a scammer includes updating security software, running a scan, removing what it identifies, changing passwords, and turning on two-factor authentication.^{FTC: What To Do if You Were Scammed}

For a serious compromise—especially one involving banking, intimate/private data, employer systems, persistent remote access, or malware that returns after removal—consider professional help. Reinstalling or resetting a device can be appropriate when trustworthy cleanup cannot be established, but preserve important data and recovery information first when it is safe to do so.

9. If money or identity information may be involved

Contact the bank, card issuer, payment service, carrier, or other affected institution using a known official channel.
Report internet-enabled fraud to the FBI's Internet Crime Complaint Center when appropriate and preserve transaction IDs, messages, account information, dates, and payment details.
Use IdentityTheft.gov for a personalized U.S. identity-theft recovery plan when personal information is being misused.
If identity theft or exposed identity information creates a risk of new credit being opened, consider a credit freeze. The FTC states that freezes are free to place or lift, do not affect a credit score, and remain until lifted.^{FTC: Get a credit freeze to stop identity thieves}

Acting quickly matters, but speed should not mean trusting the first “recovery agent” who contacts you. The FBI has warned that scammers impersonate IC3 personnel and target people who have already lost money. A promise that someone can recover stolen cryptocurrency or funds for an upfront payment is a reason for independent verification.

10. Make security easier for the whole household

Household security works better when the plan is simple enough that people will actually use it. Avoid turning every suspicious message into a test people can fail. Make it normal to ask another family member before sending money, entering a verification code, installing remote-support software, or responding to an unusual emergency request.

Create a small shared plan

Choose a known way to verify urgent requests from family members if a phone or social account is compromised or a voice/video impersonation is used.
Know who can help recover the primary household email, phone-carrier, and cloud accounts.
Teach children and less-technical family members that asking for help before clicking or paying is a security control, not a failure.
Keep important recovery contacts and device purchase/support information somewhere available during an outage or account lockout.
Review devices and high-value accounts a few times per year and after a move, device replacement, breakup, death, or other household change that affects access.

A practical 30-day home security reset

Today

Secure primary email with a unique credential and stronger authentication.
Update the phone and computer you use for banking and account recovery.
Review active sessions and recovery methods on primary email and financial accounts.
Confirm that irreplaceable data has at least one recoverable backup.

This week

Move reused passwords to unique credentials using a password manager if helpful.
Enable passkeys or stronger MFA on high-value accounts where supported.
Update the router, change default administrator credentials, and verify WPA2/WPA3 configuration.
Inventory smart devices and remove ones you no longer use or cannot identify.

This month

Test restoring important files from backup.
Review smart-device support status, permissions, and remote-access features.
Discuss the household verification plan for urgent money/account requests.
Write down official recovery paths for the few accounts whose loss would create the most damage.

Primary and current reference set

Latest cybersecurity briefings

Use current advisories as context, not as a substitute for the durable controls above.

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.

GitHub Security Lab
Android security
AI security agents
Application security
Taskflow Agent

Open dedicated page

Coverage note: This Zeph Tech briefing was published on September 29, 2026 and covers GitHub Security Lab research published on September 28, 2026. 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.

Documentation

How we found 24 Android vulnerabilities using our open source AI security agent — GitHub Security Lab
Community-powered security with AI: an open source framework for security research — GitHub Security Lab

Open as standalone page

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.

Citrix NetScaler
CVE-2026-88771
CVE-2026-88772
Active exploitation
Edge security

Open dedicated page

Coverage note: This Zeph Tech briefing was published on September 29, 2026 and covers Citrix’s September 27, 2026 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.

Related Zeph Tech guidance

Use the Vulnerability Management Program guide to structure emergency ownership and verification, the incident response plan template to coordinate evidence and recovery, and the risk register to track residual exposure and temporary exceptions.

Documentation

NetScaler ADC and NetScaler Gateway Security Bulletin CTX697096 — Citrix
Exploitation of vulnerabilities affecting Citrix NetScaler ADC and Citrix NetScaler Gateway — UK National Cyber Security Centre

Open as standalone page

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.

GitHub Copilot
Local sandboxing
AI agents
Developer security
Least privilege

Open dedicated page

Coverage note: This Zeph Tech briefing was published on September 29, 2026 and covers GitHub’s September 23, 2026 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.

Related Zeph Tech guidance

Use the Developer Enablement guide to integrate secure tooling into engineering workflows, the Vulnerability Management Program guide to manage findings, and the risk register to document residual risks such as sandbox exceptions and credential exposure.

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.

Related Zeph Tech guidance

Use the Developer Enablement guide to manage tooling baselines, the Vulnerability Management Program guide for controlled remediation, and the risk register to assign owners for legacy SSH dependencies and time-bound exceptions.

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.

Related Zeph Tech guidance

Use the Vulnerability Management Program guide to turn urgent advisories into a repeatable remediation workflow, the free cybersecurity risk register to record residual exposure and treatment ownership, and the Cybersecurity hub for broader defensive guidance.

Scope the operational blast radius

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.

Cited sources

Microsoft Security Update Guide — CVE-2026-65660 — Microsoft
Description of the security update for SharePoint Server Subscription Edition: September 08, 2026 — Microsoft

Open as standalone page

Source feedback

Editorial

Found a factual issue, superseded source, broken citation, or important context we should review? Send the specific claim and supporting source through the correction path so it can be evaluated against the article record.

Request a correction or source review Read the editorial standards

Continue learning

Related guides after Cybersecurity Guide for Home Users

Follow the next implementation topic without returning to search.

Turn Cybersecurity Guide for Home Users into a decision-ready next step.

Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.

Build an evaluation brief Browse Cybersecurity research Explore the full resource library See where ZephCMS may fit

Start with the controls that prevent one mistake from becoming ten

The order matters

1. Protect your accounts and recovery paths

Use unique passwords, not password formulas

Use a password manager when you have many accounts

Prefer stronger authentication when an account offers it

Protect account recovery with the same care as login

2. Treat unexpected urgency as a reason to verify

Stop before you act

Do not execute commands copied from a website or message unless you understand them

3. Keep phones and computers supported, updated, and locked

Use the security features already in the device

4. Secure the home router without guessing at its interface

5. Buy and operate smart devices with the support lifecycle in mind

Before buying

After setup

6. Back up what cannot be recreated

A useful backup has independence and history

7. If an account is taken over

8. If you think malware or remote-control software was installed

9. If money or identity information may be involved

10. Make security easier for the whole household

Create a small shared plan

A practical 30-day home security reset

Today

This week

This month

Primary and current reference set

Latest cybersecurity briefings

Source feedback

Related guides after Cybersecurity Guide for Home Users

Small Business Cybersecurity Survival Checklist

Network Security Fundamentals

Zero Trust Frameworks

Turn Cybersecurity Guide for Home Users into a decision-ready next step.