I go through about 700-900 cybersecurity newsstories every week and pull out the most interesting stories. Then I turn them into this short, digestible summary, so you can stay up to date without trying to follow 25 different sources yourself. 😱
My aim is to create a summary that gives you the gist without needing to open up the source article. But if you do want to dig deeper, all the sources covering the event are linked below each story.
If you enjoy these, come back next Monday
scroll to the bottom to subscribe to the e-mail newsletter.
Claude Code makes “auto mode” the default after tests showed humans approve 97% of risky prompts
Anthropic is changing Claude Code so an automated safety classifier (“auto mode”) becomes the default for new sessions on Pro, Max, and Team plans starting August 14, 2026, replacing the prior model of frequent human permission prompts. Anthropic says testing found “approval fatigue” — users reflexively approved most prompts — while auto mode more consistently blocked irreversible, destructive, or out-of-environment actions.
Key Details
- In a controlled study with 1,053 paid professional testers, humans caught only 13.6% of inserted dangerous commands while auto mode blocked 89%.
- Anthropic observed users approved 97% of permission prompts, and human catch rates dropped from 17% early in sessions to 5% after 50+ prior prompts; auto mode’s detection stayed consistent.
- Auto mode blocked 800 commands humans approved, while humans blocked 6 commands that auto mode missed.
- When auto mode flags an action, Claude typically tries a safer alternative or asks for confirmation; after three consecutive blocks (or 20 total in a session) Claude Code falls back to manual approvals.
- Scope: default applies to new sessions on Pro, Max, and Team; it remains opt-in for now on Claude Enterprise, Claude API, and platforms like AWS/Bedrock, Google Cloud, and Microsoft Foundry (with Anthropic indicating broader defaulting in the following month).
Next Steps
- For orgs piloting agentic coding, run a controlled evaluation of auto mode vs manual prompts on your own workflows (including destructive/out-of-environment scenarios) and document when your teams hit the “fallback to manual” thresholds.
Read more at Cyber Security News, Talkback.sh
Researchers show how GitHub’s own event stream can detect supply-chain attacks via forged identities, poisoned tags, and workflow/OIDC abuse
Researchers proposed an “EDR for GitHub” approach that turns GitHub’s native telemetry (webhooks, API events, and repo inspection) into behavioral detections for common software supply-chain attack techniques. They argue many recent incidents could have been identified earlier by correlating GitHub-side signals—especially where attackers try to look legitimate in Git history while GitHub still records who actually performed the actions.
Key Details
- Mismatch between commit “author” metadata and the authenticated GitHub user who pushed it is a key hunting signal, since Git commit metadata can be forged even when GitHub’s push identity is recorded separately.
- Reused forged maintainer identities (e.g., the same author email across multiple repos) can connect otherwise unrelated compromises into a broader campaign, according to the researchers’ analysis of multiple supply-chain incidents.
- “Mass tag poisoning” detection focuses on spotting force-moved release tags (e.g., @v1) being repointed to malicious commits by tracking tag history via the GitHub API and comparing previous vs. current commit references.
- Workflow tampering to enable OpenID Connect (OIDC) token issuance is highlighted as a modern pattern: attackers modify workflows to mint short-lived identities for cloud/package registries instead of stealing long-lived secrets.
- The open-source “GitHub Threat Detector” reportedly ships with 22 production and 12 beta rules, plus “compound” detections designed to combine weaker signals into higher-confidence alerts; the researchers note constraints like webhook disablement, API rate limits, and non-real-time Git inspection.
Next Steps
- Deploy and evaluate “GitHub Threat Detector” against your org’s GitHub orgs/repos (start with a pilot on high-value repositories) to baseline noise and validate detections against your normal workflow.
Read more at CSO Online
‘Ghostjacking’ poisons security logs and alerts to trick AI coding agents into executing attacker commands
Tenet Security demonstrated “Ghostjacking,” where attackers embed malicious instructions into trusted operational data (logs, blocked requests, alerts, bug reports) that AI agents later read and act on. Because the agent executes actions using its already-approved access (shell, cloud consoles, DNS, secrets), the attack can change cloud settings, redirect traffic, and exfiltrate credentials without a traditional software exploit.
Key Details
- Cloudflare WAF blocked the malicious request, but logged the attacker’s text verbatim; when an analyst asked an AI agent to review the event, the agent followed the embedded instructions and altered DNS to an attacker-controlled domain (Tenet reported 9/10 success against Claude Code in testing).
- Datadog was abused via publicly exposed client-side/front-end keys: Tenet said it found 2,700+ such keys online and showed an attacker could use one to create a fake “urgent diagnostic” alert that induces an AI agent to run commands and expose environment variables and cloud credentials.
- Sentry’s AI assistant (Seer) enabled an “AI-to-AI trust” chain, where Seer ingests a crafted issue report and outputs an attacker-influenced recommendation that a separate coding agent may execute without seeing the original malicious content.
- Tenet also reported a Claude Desktop sandbox escape that Anthropic patched (no CVE mentioned), which could have allowed agent-collected data to leave a restricted sandbox.
- The researchers framed the core failure mode as “trusted read + privileged action” in the same workflow, arguing the pattern can extend beyond the named products to other toolchains where agents both consume operational data and can execute changes.
Next Steps
- Require human approval for AI-agent command execution and sensitive changes (e.g., DNS, IAM, cloud configuration), especially when the trigger is log/alert/issue-review workflows.
- Segment untrusted operational text from agent instructions by design (treat logs/alerts/bug reports as untrusted input and prevent them from being interpreted as executable guidance).
Read more at Cyber Security News, Talkback.sh, Dark Reading
Blacklight open-sources endpoint toolkit to enumerate local AI agent artifacts (tokens, chats, configs) across popular coding assistants
SpecterOps released Blacklight, an open-source toolkit that discovers and analyzes local AI agent artifacts on endpoints to help security teams assess exposure and build detections and hardening guidance. It focuses on artifacts left behind by locally used agents (currently including Codex, Claude Code, Cursor, and Antigravity/Gemini CLI) that can reveal authentication material, trusted integrations, and detailed user activity. This has great applications for - data monitoring, DFIR investigations, and shadow IT detection.
Key Details
- Artifact categories include auth material, settings, sessions/chat content, activity indexes, workspace metadata, rules/permissions, and integration data, which can collectively reveal user identity, current projects, trusted roots, and connected systems even when raw secrets aren’t present.
Next Steps
- Evaluate Blacklight from the official GitHub repo to reproduce the exposure assessment in a controlled, authorized manner: https://github.com/SpecterOps/Blacklight
Read more at SpecterOps, Cyber Security News
OpenAI expands Daybreak with Codex Security updates, limited-release GPT‑5.5‑Cyber, and a partner program aimed at speeding vulnerability patching
OpenAI announced an expanded Daybreak initiative focused on shifting cyber defense from finding bugs to patching vulnerable software “at machine speed”, combining model-assisted validation, prioritization, and patch generation with human review. The company also introduced a broader ecosystem approach—tools, a vetted-defender model release, and partner delivery—to move from vulnerability findings to deployed fixes across widely used software.
Key Details
- Updated Codex Security plugin adds out-of-the-box workflows to scan codebases/changes, generate severity-based reports with validation evidence and remediation guidance, trace attack paths, build threat models, and generate codebase-specific patches for review.
- OpenAI says Codex Security (research preview since March) has scanned 30M+ commits across 30,000+ codebases, with 70,000+ findings manually marked fixed and 500,000+ findings automatically determined fixed.
- GPT‑5.5‑Cyber is moving from a permissive-only preview to a full version distributed via a continued limited release to “trusted defenders,” paired with additional verification, monitoring, scoped controls, and review.
- On OpenAI’s reported benchmarks, GPT‑5.5‑Cyber scored 85.6% on CyberGym (vs 81.8% for GPT‑5.5) and also exceeded GPT‑5.5 on ExploitGym (39.5% vs 25.95%) and SEC-bench Pro (69.8% vs 63.1%).
- The Daybreak Cyber Partner Program lets security vendors and service providers offer GPT‑5.5 with “Trusted Access for Cyber” inside their products/services, keeping direct model access with participating partners; OpenAI also highlighted “Patch the Planet,” with 30+ open-source projects committed (including cURL, Go, Python, Sigstore, and pyca/cryptography).
Next Steps
- For orgs with large remediation backlogs, evaluate whether the Codex Security plugin fits your SDLC by piloting scans on a representative repo and testing SARIF/CodeQL export into your existing vulnerability management workflow: https://openai.com/daybreak/codex-security-plugin/
- If you maintain or depend heavily on key open-source components, consider engaging with Patch the Planet to speed “finding-to-fix” cycles in upstream projects: https://openai.com/index/patch-the-planet/
Read more at OpenAI, SiliconAngle, Cyberscoop
GhostSplice prompt-injection splits malicious instructions across MCP tool metadata and outputs to trick AI coding agents into exfiltration
Researchers demonstrated “GhostSplice,” where a malicious MCP tool server fragments an exfiltration request across otherwise normal-looking tool descriptions/results so an AI coding agent reconstructs it and leaks local secrets. In controlled tests, splitting the instruction significantly increased model compliance, and results varied by client guardrails—showing the surrounding tool-invocation and trust model can be as important as the underlying LLM behavior.
Key Details
- The attack assumes a developer has already connected an attacker-controlled MCP server, and that the agent already has read access to the files being targeted (it’s not a remote break-in by itself).
- One reference implementation disguises exfiltration as “form filling”: a benign-looking tool (e.g., “integrity_checker” with generic fields) is paired with a later “mapping” that instructs the agent to populate those fields with contents from sensitive files like SSH keys, .env secrets, source code, or customer data.
- Splitting one malicious request into two raised average compliance from 42% to 82% across 11 API-tested models (per ASSET’s disclosure), with some models reportedly jumping from 0% (single prompt) to 100% (split prompts) under the test setup.
- Client differences materially changed outcomes: the same model could refuse in one coding client but exfiltrate in another depending on tool-safety controls and how untrusted server content is handled.
- Guidance cited by the researchers emphasizes treating server-provided text as untrusted data and preventing unchecked “tool-output → tool-argument” flows that let injected instructions propagate through the agent’s toolchain.
Next Steps
- Restrict MCP server integrations to an allowlist and require human approval for adding new/custom MCP servers (per the MCP spec/OpenAI guidance on untrusted servers increasing prompt-injection risk).
- Implement a strict “data-only” boundary for MCP server outputs: don’t allow tool results/annotations from untrusted servers to directly populate arguments for subsequent tools without validation/escaping and explicit user confirmation.
Read more at Cybersecurity Reddit, The Hacker News, Talkback.sh
FTC floats treating “ideological bias” in AI as a deceptive practice, signaling it could override state AI laws
The FTC proposed a policy framework that would treat ideological bias in AI systems as an “unfair or deceptive” practice under Section 5, potentially expanding consumer-protection enforcement into how models are trained or shaped. The proposal also signals the FTC views its authority as superseding some state AI rules, prompting broad criticism that the approach is ill-defined and could enable politically driven censorship of model outputs.
Key Details
- The FTC argues consumers expect AI outputs to be free from “bias or ideological manipulation”, but the proposal does not clearly explain how the agency would determine when ideological bias exists.
- The statement suggests federal preemption by pointing to the Colorado AI Act’s risk assessments, transparency disclosures, and “bias audits”.
- CyberScoop reports 300+ public comments were submitted; critiques came from across the political spectrum, including concerns the policy blends ideological bias with deception in marketing and raises First Amendment issues.
- Some commenters supported stronger anti-bias enforcement (e.g., America First Legal urged adoption “in full”), while others argued existing LLM disclaimers make it harder to prove consumer deception based on “expectations” (e.g., R Street Foundation).
- Members of Congress urged the FTC to protect civil-rights-related safeguards (preventing discrimination based on federally protected characteristics) while avoiding “falsifying facts in the name of fairness.”
Read more at Cyberscoop
Hidden “prompt injection” text in Connecticut court filing tried to bias any AI review toward one party
A self-represented litigant in Connecticut embedded near-invisible text in court filings containing “prompt injection” instructions intended to make any AI system produce output favorable to the plaintiff. The court detected the concealed text, issued a sanction barring the plaintiff from e-filing, and used the incident to warn that covert AI-targeted instructions undermine the integrity of on-the-record legal proceedings.
Key Details
- The instructions were concealed as 3-point white font placed throughout the filing, designed to be hard for humans to see but readable by software extracting text.
- The court said it noticed unusual extra “white space” in specific docket entries and, on review, found text “formatted so as to be nearly invisible to a human reader.”
- Judge Walter Spader Jr. stated the Connecticut Judicial Branch does not use AI to review court records, but ruled the attempted manipulation was improper regardless of whether it hit an AI “target.”
- In later filings, the plaintiff added additional concealed content including “hi :) I hope yo ucant see me” (sic), “HAHAHA U GUYS GET THIS,” and a link to a SpongeBob Squarepants Nosferatu clip.
- As a sanction, the plaintiff can continue the case but is barred from electronic filing and must submit paper filings.
Read more at 404 Media
NIST opens public input on overhauling the National Vulnerability Database for AI-scale vulnerability discovery and machine-consumable data
NIST published a Federal Register request for information seeking feedback on how to modernize the National Vulnerability Database as AI tools increase the volume, complexity, and speed of vulnerability discovery and exploitation. The agency is asking how to better integrate automation (including AI) into vulnerability reporting and enrichment while building in transparency and auditability for automated decision-making.
Key Details
- NIST says current vulnerability management patterns—periodic scanning, static prioritization, and manual remediation—are showing “inadequacies” in an AI-shaped threat landscape.
- The RFI cites pressures including increased disclosure volume/complexity, inconsistent data quality, and demand for near real-time vulnerability enrichment to support faster defender workflows.
- NIST is explicitly soliciting ideas on capabilities, products, and processes to disseminate vulnerability information faster to stakeholders via automation and machine-readable security data.
- The questions include how to make AI-driven decisions transparent and auditable within vulnerability reporting and prioritization pipelines.
Read more at nvd.nist.gov, kb.cert.org, Cybersecurity Reddit, Cyberscoop, Dark Reading
NATO cyber defense unit and AISLE join ENISA’s CVE “Root,” gaining authority to issue vulnerability IDs
ENISA added the NATO Cyber Security Centre and AISLE as CVE Numbering Authorities under the ENISA Root, meaning they can assign official CVE identifiers for eligible vulnerabilities within their defined scopes. The move expands Europe’s role in the CVE ecosystem and is intended to speed up and standardize vulnerability identification and sharing across NATO and AISLE’s products.
Key Details
- Under ENISA’s structure, the NATO Cyber Security Centre can assign CVEs across the NATO enterprise, which NATO says will improve consistency and allow earlier sharing with trusted partners.
- AISLE’s CNA scope is limited to vulnerabilities in AISLE’s own products, enabling it to publish CVE IDs without waiting on a third-party CNA to process requests.
- ENISA linked the expansion to Frontier AI models affecting vulnerability discovery and exploitation, and framed the goal as a more resilient and scalable identification ecosystem.
- The article notes ongoing ecosystem shifts after the CVE program avoided a shutdown in April 2025 via an 11-month contract extension, alongside new/competing vulnerability databases such as CIRCL’s GCVE.
Read more at AISLE, Cyberscoop
WhatsApp previews “Scam Alert” that flags likely scam messages with on-device ML and verifiable privacy controls
WhatsApp shared an early technical preview of Scam Alert, an optional feature where an on-device ML model warns users about likely scam messages without sending message content off the phone. Meta says the system is designed to preserve end-to-end encryption guarantees by limiting telemetry to anonymous aggregates and adding verifiability measures (transparency logs and published model artifacts) to prevent targeted model delivery and enable independent review.
Key Details
- Scam Alert only evaluates incoming messages from non-contacts after a user enables the feature and downloads the model to the device.
- If a chat is flagged, the warning is only visible to the recipient, who can block/report or continue; users can also mark a chat as trusted so it won’t be flagged again.
- If a user marks a warning as incorrect, they can optionally share the last 5 received messages with WhatsApp to help improve accuracy (otherwise content is not sent).
- To measure effectiveness, WhatsApp says it collects only aggregate counts of warnings and user actions, processed using a confidential computing pipeline (TEE/CVM) and released as differentially private aggregates.
- Meta says it will prevent per-user targeting by requiring that all model versions are published to a public transparency ledger before deployment, and by publishing model weights for independent verification that the model is purpose-built for scams.
Read more at Engineering at Meta, Cyber Security News
UK criminal records office left public portal unpatched for years; attackers kept access for 7 months and staged data on ~11,000 people
The UK Information Commissioner’s Office (ICO) reprimanded ACRO after investigators found that attackers maintained persistent access to ACRO’s website/Kentico CMS for ~7 months and staged sensitive data for possible exfiltration. The incident stemmed from basic operational gaps—missed patches, unclear vendor/owner responsibility, unread security alerts, and insufficient logging—making it impossible to confirm whether data was actually stolen.
Key Details
- ACRO ran Kentico CMS v12.0.0 from Sept 2019 to March 2023 without applying patches/hotfixes, leaving known vulnerabilities unresolved.
- Ambiguity between ACRO and its managed service provider over who owned patching meant neither party actively monitored and applied Kentico security updates.
- Trend Micro alerts went unreviewed; the ICO said ACRO could not show what process or roles existed to assess and handle security alerts at the time.
- Investigators found data staged for potential exfiltration on Feb 15–16, 2023; potentially exposed information included ID and financial data (NI numbers, passport/driving licence details, bank details), biometric data, and sensitive criminal offence/special category information.
- 84,048 people were notified, but the ICO later assessed that data relating to no more than 10,920 individuals was potentially staged for exfiltration; ACRO received 35 complaints and the ICO received six.
Next Steps
- Review vendor relationships to make sure there is no ambiguity in who is responsible for monitoring and patching of systems.
Read more at Talkback.sh, The Record
White House creates program to let vetted US security firms conduct government-directed offensive cyber ops against foreign cybercrime gangs
A new White House memorandum directs the National Coordination Center to stand up a program that authorizes vetted US companies to carry out government-controlled “cyber surveillance” and “cyber effects” operations against foreign cyber-enabled transnational criminal organizations. The move formalizes a mechanism for private-sector operators to help disrupt criminal infrastructure overseas while operating under federal oversight and legal authorities.
Key Details
- Participating firms must sign contracts with DOJ or DHS requiring rigorous vetting and adherence to government-set operating procedures; eligibility criteria are intended to include both large and smaller specialist companies.
- Operating procedures due within 60 days must include target-validation and deconfliction processes across federal law enforcement and other US government equities, with an adjudicatory framework to ensure operations target only CE‑TCOs.
- The memorandum allows participating firms to receive threat information via commercial agreements from private entities (collected in normal business) and from federal/state/local/tribal/territorial agencies to propose operations to the NCC.
- Contracts may require firms to maintain a bond/escrow of at least $1 million, forfeitable for non-compliance, and include requirements to stop and report if activity exceeds approved parameters (e.g., accidental targeting involving US persons or US-based systems).
Read more at The White House, SiliconAngle, Cyberscoop, The Record, Talkback.sh
Beacon CRM says attacker likely downloaded a readable copy of its full customer database after exposed AWS access key
Beacon CRM said investigators assess that a copy of the database holding all customer data (including attachments) was likely exported and downloaded in readable form during unauthorized access to its AWS environment. The suspected entry point was a compromised AWS access key potentially exposed in public JavaScript build artifacts, with activity observed on July 27, 2026 for roughly 87 minutes.
Key Details
- Beacon’s investigators correlated a significant data-transfer spike on 27–28 July 2026 with the incident using AWS Cost & Usage reports (May–July 2026).
- Beacon said available logs could not determine which specific objects were accessed or the destination, but the transfer volume led to an assessment that all database data was exported.
- Beacon noted data was encrypted at rest in AWS, but because valid credentials were used, AWS would have provided the data decrypted to the attacker during access/download.
- Beacon reported no persistence mechanisms identified and said it reset credentials for services/accounts integrated with AWS after remediating the likely exposure.
- Beacon said it reported the incident to the UK ICO (case IC/0238/2026) and advised customers to make their own notification/risk assessments based on the data they stored in Beacon.
Next Steps
- Use this as a cautionary tale in your information security trainings.
- If your organization uses Beacon, assume all data stored in Beacon (including attachments) may be exposed and complete your internal impact assessment and any required notifications using Beacon’s guidance: https://www.beaconcrm.org/incident-guidance
Read more at beaconcrm.org, Talkback.sh, Cyber Security News, Talkback.sh
DecryptAds launches free adtech transparency service that maps who can track users across websites and apps
A new free service, DecryptAds, scrapes and correlates semi-public adtech disclosure files to show which companies are authorized to serve ads or collect data on specific sites and apps. By cross-referencing these declarations, it aims to make it easier to spot risky ad partners, data brokers (including those collecting geolocation), and patterns associated with malvertising or low-quality “AI slop” sites.
Key Details
- DecryptAds aggregates and cross-references ads.txt, app-ads.txt, and buyers.json/sellers.json to build a supply-chain view that’s difficult to derive from any single file.
- In an example profile, DecryptAds reports ESPN’s declared relationships include 143 ad partners and 19 registered data broker domains found in its ads.txt and app-ads.txt disclosures.
- DecryptAds’ “Geo Risk” labeling highlights adtech partners based in countries it flags as higher-risk (e.g., China and Russia) or with strong ties (e.g., Cyprus and UAE), and it surfaces ownership/beneficiary information where available.
- A “Legal Dossier” feature compiles domain/app background and relationships (e.g., shared seller IDs across seemingly unrelated properties) to help pivot from one entity to a broader adtech network.
- DecryptAds includes a “quiet removals” feed tracking sellers.json removals across exchanges to expose when entities disappear from approved lists without public explanation.
Next Steps
- Use decryptads.com to inventory your organization’s domains/apps and identify unexpected ad partners, data brokers, and geo-risk relationships.
- If you run web/app properties, review and tighten ads.txt/app-ads.txt entries to ensure only intended sellers/resellers are authorized and remove unknown or unnecessary partners.
- Good pages to test the service are news portals.
Read more at Krebs on Security, 404 Media
Zoom patches zero-click RCE in meeting annotation protocol affecting multiple clients (CVE-2026-53413/53414)
Zoom released fixes for vulnerabilities that could allow zero-click remote code execution during a live meeting via crafted annotation traffic, requiring only that a target be present in the meeting. The issues stem from how native clients parse Zoom’s proprietary annotation protocol messages, enabling memory corruption and code execution when maliciously formed data is processed.
Key Details
- Tracked as CVE-2026-53413 and CVE-2026-53414 in Zoom security bulletins; Zoom also notes a third related issue, CVE-2026-53415, that it says was already found and fixed before the external report.
- The vulnerable surface is Zoom’s annotation feature and its proprietary message format, where receivers automatically deserialize attacker-controlled fields (e.g., lengths/counts) into in-memory objects rather than treating the content as inert pixels.
- Reports describe the attack as meeting-context RCE with no user interaction—no clicks or downloads—triggered by messages sent within the meeting’s annotation channel.
- The a.security write-up states the bug was present up to and including Zoom 7.0.5, and warns that certain configurations remained affected until later client updates (it calls out clients before 7.1.5 and 7.0.6 when using end-to-end encryption settings).
- Zoom says it implemented both client-side and server-side mitigations as part of the remediation, and published guidance via its security bulletins.
Next Steps
- Update Zoom Workplace clients to fixed versions
Read more at a.security, Zoom, Cybersecurity Reddit, CSO Online, CyberInsider, Cybersecurity Reddit, Cyber Security News, SecurityWeek, WIRED, The Hacker News, Zoom
NIST publicly launches ArtCat, a community-contributed catalog to standardize interpretation of digital forensic artifacts
NIST has publicly released the Digital Forensics Artifact Catalog (ArtCat), a curated, queryable repository intended to help practitioners consistently extract and interpret digital evidence. The catalog’s core idea is to standardize around “atomic artifacts” (individual, inference-bearing data elements) with platform/app version context and citations, turning fragmented practitioner knowledge into shareable, version-aware reference infrastructure.
Key Details
- ArtCat is positioned as practitioner-built, community-contributed, and curated to address unstructured and sometimes incomplete ad hoc knowledge-sharing in digital forensics.
- Entries are designed to be version-aware and traceable, with the ability to add, revise, refine, and track change history over time.
- Artifacts can be classified using CASE (Cyber-investigation Analysis Standard Expression) ontology concepts to support a common language and machine-readable representation.
Next Steps
- Have DFIR leads and tool owners evaluate ArtCat for your top evidence types (e.g., geolocation, device linkage) and map relevant “atomic artifacts” to your collection/playbooks.
- If your team develops scripts/parsers or maintains internal artifact notes, pilot contributing or aligning entries with ArtCat (including version context and citations) via https://artcat.nist.gov/.
Read more at artcat.nist.gov, CKE Ltd.
Subscribe
Subscribe to receive this weekly cybersecurity news summary to your inbox every Monday.
