Microsoft Secure Default Exchange and Teams

Microsoft Strengthens API Security for Exchange and Teams with Admin Approval Requirement

As part of its ongoing efforts to strengthen cloud security, Microsoft is introducing a major policy update that will require administrator approval for all new third-party applications seeking access to Exchange and Teams data.

This change, part of Microsoft’s broader Secure Future Initiative, is scheduled to roll out between late October and late November 2025. The update falls under Microsoft’s “Secure by Default” approach, designed to tighten access controls and protect organizational data across Microsoft 365 environments.

What’s Changing and Why It Matters

The core of this update involves changes to the default consent policy managed by Microsoft. Moving forward, any new third-party app requesting access to Exchange or Teams content via APIs such as Microsoft Graph, Exchange Web Services, Exchange ActiveSync, POP3, or IMAP4 will now require explicit administrator approval before access is granted.

This policy does not impact existing apps that users have already authorized. However, if an app requests new permissions or a new user tries to authorize it, the administrator consent process will be triggered.

Organizations that have already implemented custom user consent policies will remain unaffected by this change.

A Consistent Security Approach Across Microsoft 365

This move aligns with previous Microsoft efforts to improve baseline security, including earlier changes to SharePoint and OneDrive, where legacy protocol access was blocked and admin consent was required for file-level third-party access.

By expanding this model to Exchange and Teams, Microsoft continues to harden its platform against potential abuse and unauthorized data access, without requiring customers to purchase additional licenses.

What IT Teams Should Do Now

To prepare for the rollout, Microsoft recommends several key actions for IT administrators:

  1. Review Existing Permissions
    Audit your current environment to identify third-party applications accessing mail, calendars, contacts, and Teams chat or meeting data.
  2. Enable the Admin Consent Workflow
    Set up the admin consent request workflow in Azure AD (Entra ID). Without this, users won’t have a way to request access to blocked apps.
  3. Create App Access Policies for Trusted Apps
    For critical third-party tools your organization relies on, preemptively create granular app access policies to avoid disruption.
  4. Communicate the Changes
    Inform IT teams, app owners, and security personnel about the upcoming policy shift. Update on-boarding documentation and internal guidelines accordingly.

This policy update underscores Microsoft’s commitment to improving tenant security by default, giving administrators greater control and visibility into third-party integrations. With rising threats targeting collaboration platforms and messaging systems, this is a timely and necessary evolution in Microsoft’s security posture.

red-hat-history-shadowman

Red Hat Confirms Major Security Breach Involving Internal GitLab Instance

Red Hat, widely recognized as the world’s leading provider of enterprise open-source solutions, has confirmed a significant cybersecurity incident involving unauthorized access to an internal GitLab server used by its Consulting team.

The breach, now under active investigation, follows claims by the hacker group Crimson Collective, who allege they exfiltrated approximately 570GB of compressed data from over 28,000 private repositories. If accurate, this would mark one of the most substantial source code leaks in recent memory.

Red Hat Consulting GitLab Environment Is The Target

According to Red Hat’s official disclosure, the breach targeted a GitLab environment used for collaboration within Red Hat Consulting, supporting engagements with select clients. An unauthorized third party was able to access and extract data from the server before detection.

In response, Red Hat initiated a full-scale investigation, cut off attacker access, isolated the compromised system, and alerted the relevant law enforcement agencies. The company has since rolled out additional security hardening measures.

What Was Exposed?

Initial reports suggest the stolen data includes a vast trove of sensitive technical assets, such as:

  • CI/CD secrets and pipeline configurations
  • VPN profiles and infrastructure blueprints
  • Ansible playbooks and OpenShift deployment guides
  • Container registry configurations and Vault integration secrets
  • SSH keys, API tokens, and database credentials

Security researchers examining the data found references to thousands of organizations, spanning multiple critical sectors. These include major financial institutions like Citi, JPMC, and HSBC, telecom giants such as Verizon and Telefonica, industrial leaders like Siemens and Bosch, and even U.S. government entities, including the U.S. Senate.

Potential Supply Chain Risks

The breach is being described as a supply chain threat, as many of the exposed repositories contain Infrastructure-as-Code templates, automation scripts, and configuration files that could be weaponized in secondary attacks.

Particular concern are:

  • Kubernetes deployment manifests
  • Container registry credentials
  • GitLab CI/CD runner configurations
  • Privileged deployment pipelines

These components often carry elevated access within enterprise environments, making them prime targets for lateral movement or persistent backdoor access.

Red Hat’s Response & Ongoing Investigation

Red Hat has emphasized that its main software supply chain and official distribution channels remain unaffected. The breach is not linked to the recent CVE-2025-10725 vulnerability involving OpenShift AI services.

While forensic analysis is still ongoing, Red Hat has committed to notifying any Consulting clients directly affected by the breach. The company continues to work with cybersecurity experts and authorities to fully understand the incident’s impact.

openssl-1280-hns

OpenSSL Flaws Enable Remote Code Execution and Private Key Recovery

The OpenSSL Project has issued a critical security advisory highlighting three major vulnerabilities that could enable remote code execution and the potential recovery of private cryptographic keys.

These security flaws affect various OpenSSL versions across multiple platforms, posing risks such as memory corruption, denial of service, and unauthorized access to sensitive cryptographic data.

The most serious of these issues is tracked as CVE-2025-9230, rated with moderate severity. It stems from out-of-bounds memory operations in the implementation of the RFC 3211 Key Encryption Key unwrap functionality.

This vulnerability is triggered when applications decrypt Cryptographic Message Syntax messages using password based encryption. Exploitation may result in out-of-bounds read and write operations, leading to memory corruption. If successfully exploited, attackers could execute arbitrary code or crash the affected system.

Memory Corruption Vulnerability

CVE-2025-9230 is a vulnerability in OpenSSL that stems from improper handling of Cryptographic Message Syntax message decryption. It affects a wide range of versions, including 3.5, 3.4, 3.3, 3.2, 3.0, 1.1.1, and 1.0.2.

The flaw is triggered when an application attempts to decrypt specially crafted messages that use password based encryption. This can lead to out-of-bounds memory access, including write operations that may corrupt memory. An attacker exploiting this could potentially overwrite critical memory regions, enabling the execution of shellcode or arbitrary commands.

Discovered by Stanislav Fort and the Aisle Research team on August 9, 2025, the vulnerability arises from insufficient bounds checking in the Key Encryption Key unwrap algorithm. Specifically, the code fails to properly validate buffer boundaries, making it possible for attackers to exploit integer overflows and trigger buffer overflows during decryption.

Although the exploit requires certain conditions, namely, the use of password based encryption in Cryptographic Message Syntax messages its impact is severe. Fortunately, password-based encryption is rarely used in real-world deployments, limiting the attack surface. Additionally, OpenSSL FIPS modules are not affected, as the Cryptographic Message Syntax implementation lies outside the FIPS boundary.

If exploited, this vulnerability could result in full remote code execution, leading to complete system compromise.

Timing Side-Channel Flaw

The second critical vulnerability, CVE-2025-9231, introduces a timing side-channel flaw in the SM2 cryptographic algorithm implementation on 64-bit ARM platforms.

According to the OpenSSL advisory, this vulnerability could allow remote attackers to recover private keys by analyzing timing variations during cryptographic operations specifically, during SM2 signature generation.

Although OpenSSL does not natively support SM2 certificates in TLS contexts, the risk arises in environments where custom cryptographic providers enable SM2. In such cases, the vulnerability may be exposed in production deployments.

Timing side-channel attacks exploit minute variations in how long cryptographic operations take to execute. In this case, discrepancies in SM2 signature computation create measurable timing patterns, which can be analyzed remotely to reconstruct private key material. These attacks typically require repeated observations over the network, but they are feasible under the right conditions.

This vulnerability specifically affects OpenSSL versions 3.5, 3.4, 3.3, and 3.2 on 64-bit ARM architectures. Earlier versions 3.1, 3.0, 1.1.1, and 1.0.2 are not affected due to differing implementations of the SM2 algorithm.

Another issue, CVE-2025-9232, involves an out-of-bounds read in the OpenSSL HTTP client when handling IPv6 addresses in the no_proxy configuration. This flaw is considered lower risk and is limited to potential denial-of-service outcomes.

Organizations using custom providers that support SM2 are strongly urged to apply patches immediately to mitigate the risk of private key exposure via timing analysis.

Patched versions include:

  • OpenSSL 3.5.4, 3.4.3, 3.3.5, 3.2.6
  • OpenSSL 3.0.18, 1.1.1zd (premium support)
  • OpenSSL 1.0.2zm