Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Latest News

Microsoft Copilot Flaws Could Expose User Data With One Click

  Microsoft Copilot Personal contains three vulnerabilities that could allow an attacker to execute a malicious prompt with one click and ex...

All the recent news you need to know
Workflow Injection
CI/CD Security Command Injection Copilot Autofix GitHub security Jira API Token Snowflake GitHub Actions Snowflake Security Vulnerabilities and Exploits Workflow Injection

Critical Snowflake GitHub Actions Flaw Exposes Projects to Command Injection


Snowflake’s public snowflakedb/snowflake-connector-net repository has been identified as vulnerable to GitHub Actions workflow injection. This vulnerability could be exploited to trigger command execution within CI/CD workflow through specially crafted GitHub issues. In this case, the flaw is attributed to the repository’s automatic workflow, jira_issue.yml, which runs automatically when a public issue is opened. 

When processing issue data, the workflow exposed Jira credentials, including API tokens, to the affected job. Attacker-controlled issue titles and descriptions were also passed directly into a shell command, resulting in an avenue for command injection. The workflow was also triggered by an issue event, which was incorrectly referenced with github.event.pull_request.user.login as the event check reference. 

In the absence of the referenced pull request property, this condition evaluated with an empty value, resulting in regular issues reaching the vulnerable job without any protection. The issue was not related to any released versions of the Snowflake Connector for .NET and affected the repository's CI/CD automation. 

Using the Red Agent, Wiz researchers discovered the vulnerability on June 23 as part of a security research project conducted by Snowflake’s HackerOne vulnerability disclosure program. Five days prior, after pull request #1218 was merged, a security flaw had been introduced, and an unauthenticated user could activate it by using a specially crafted GitHub issue title. 

The scan conducted by GitHub Advanced Security, which included Copilot Autofix, examined a revised version containing the vulnerable workflow, however, did not identify the injection. As a result of discovering the flaw, the Red Agent verified access to sensitive information within Snowflake’s internal Jira system. Code that has been compromised originated in a cleanup-related pull request that replaced a safer environment-variable and jq parsing approach with direct interpolation of the title of an issue into a shell script, which is the source of the vulnerable code. 

GitHub's security tooling flagged other issues during the development process and Copilot suggested fixes, but neither identified the injection caused by the change. Ultimately, a human reviewer approved and merged the pull request. In June of 2026, when the workflow became active, any new issues could be accessed by the vulnerable code path. 

Wiz’s Red Agent discovered the vulnerability five days later and successfully refined its exploit after an initial attempt to exploit it failed. As a result of the resulting payload, the researchers were able to access sensitive data within Snowflake’s internal Jira environment and obtain the Jira API token, enabling them to determine the potential impact of the vulnerability. 

A number of questions are raised by the incident regarding automated security review and AI-assisted software development. Wiz pointed out that coding tools can inadvertently reintroduce unsafe shell practices, while security scanners fail to detect the injection that occurs. The case underscores the importance of thoroughly reviewing code changes involving GitHub Actions, particularly when workflows handle sensitive credentials or untrusted input. 

Snowflake was informed of the vulnerability by Wiz through HackerOne on June 23, 2026, under report #3819931. Snowflake resolved the issue on June 24, 2026, by submitting pull request #1402, which replaced direct expansion of GitHub issue data with environment variables passed as arguments to jq. The Jira token was rotated on June 24. 

The investigation conducted by Snowflake did not reveal any evidence of unauthorized access, and Wiz reported that no unrelated external use of the exposed token was observed during the five-day exposure period. There has been no release of the company's underlying audit logs. Furthermore, GitHub's commit history does not indicate that Copilot was the author of the changes to the jira_issue.yml file. 

Despite the fact that Copilot Autofix appears to be a co-author of the squash merge, the unsafe refactoring was contained in a separate commit attributed to a Snowflake developer. Consequently, the available history confirms Copilot's participation in the pull request, but does not substantiate that the code was introduced by it. 

This case demonstrates GitHub's warnings of workflow security risks in 2025, particularly when issue data is directly used in run blocks, which poses a security risk to workflows. As of August 17, 2026, no CVE, CVSS score, or CISA KEV listing had been identified for this vulnerability. The vulnerable code has since been removed from the master branch, and there is no evidence that it has been exploited outside of the master branch.
Read more »
WebKit Bugs
Apple Security Patch Vulnerabilities and Exploits WebKit Bugs

Apple Patches Dozens of WebKit Flaws in Latest Security Updates

 

Apple has issued a major set of security updates for macOS, iOS, and iPadOS after discovering dozens of vulnerabilities in WebKit, the browser engine that powers Safari and many apps across its platforms. The latest macOS Tahoe update fixes 28 flaws, 21 of them in WebKit, while older-device releases such as iOS 18.7.10 and iPadOS 18.7.10 address more than 120 bugs, including more than 40 WebKit issues. 

These bugs are serious because they affect the core component used to display web content, making malicious websites a practical attack path. Apple has not reported active exploitation in the wild, but the company urges users to install the patches quickly. The WebKit flaws can cause a wide range of problems, from Safari or process crashes to memory corruption and sensitive data disclosure. 

Some of the issues could also allow attackers to bypass sandbox protections or exfiltrate data across origins, which raises the risk of unauthorized access to private information. On macOS, additional fixes in Audio, ImageIO, IOGPUFamily, and Kernel address risks such as denial-of-service, arbitrary code execution, system termination, and kernel memory corruption. That combination makes the update important not only for browser safety, but for overall device stability and privacy. 

The most immediate recommendation is to install the updates as soon as they are available through the device’s normal software update settings. Users should not delay simply because no public exploitation has been announced, since browser-engine flaws are often attractive to attackers once details become known. Organizations should prioritize patching managed Macs, iPhones, and iPads, especially devices used for email, browsing, and access to corporate systems. It is also wise to confirm that older supported versions receive the correct maintenance release, since Apple issued separate fixes for newer and legacy branches. 

After updating, users should still practice cautious browsing habits. Avoid opening unfamiliar links in email, text messages, or social media posts, because malicious web content is the most likely delivery method for WebKit exploits. Security teams should monitor for unusual browser crashes, authentication anomalies, or unexpected data leakage, which can be early warning signs of abuse. 

If a device cannot be updated immediately, limiting web exposure and using a trusted content filter can reduce risk until patches are applied. This release is a reminder that browser engines remain a high-value target for attackers because they sit between users and the web. Apple’s broad patch set shows that a single update can close multiple pathways to compromise across consumer and enterprise devices. For most users, the safest approach is simple: update first, browse carefully, and keep security features enabled.
Read more »
data theft attack
Clop Gang Clop Ransomware Gang Cyberattacks Data Breach Data Leak data security Data Theft data theft attack

Clop-Linked Web Shell Targets PTC Windchill Servers in Data Theft Attacks

 

A custom Java web shell, associated with the Clop ransomware group, was created to target the PTC Windchill and FlexPLM servers by decrypting their credentials, enumerating file repositories, and stealing data. Researchers at cybersecurity firm ReliaQuest discovered the web shell after analyzing the recent data-theft campaign that abused the critical remote code execution vulnerability, CVE-2026-12569, affecting PTC Windchill. 

According to the researchers, the attackers did not use a traditional web shell to gain persistent access to the targeted servers. Instead, they used a custom component that demonstrated an in-depth understanding of the target application’s internal API, database schema, keystore, and file-vault structure. ReliaQuest notes that the discovered resource is an application-specific variation of the Clop ransomware group’s known mass exploitation framework. The web shell was linked to the Clop ransomware group because of extortion e-mails sent by the threat actors using the e-mail addresses associated with the data-leakage web site operated by Clop. 

In addition, the researchers identified X-windchill-req headers used by the web shell, which were also used by the Clop ransomware group in the past, as well as similar tactics, techniques, and procedures (TTPs). Earlier this year, Clop ransomware group’s infrastructure was found to target enterprise business software solutions such as Accellion FTA, GoAnywhere MFT, SolarWinds Serv-U FTP, Cleo, and MOVEit Transfer. This campaign, which affected the MOVEit Transfer application, compromised more than 2,770 organizations worldwide. 

The web shell is implemented as JavaServer Pages (JSP), which directly imports the PTC Windchill-specific classes such as MethodContext, WTConnection, and WTKeyStoreUtil, giving the threat actors’ access to PTC Windchill’s native functions, including the database, encrypted credentials decryption, and locating files stored in the application’s vaults. The web shell’s command execution capability was established using the custom protocol that utilizes the HTTP X-windchill-req header. 

Overall, the custom component allowed the attackers to achieve multiple malicious objectives, including Windchill secrets and configuration data theft, file vault discovery and enumeration, directory listing, file retrieval and deletion, executing additional Java classes, and identifying the server’s operating system. Besides that, ReliaQuest reports that the web shell’s implementation contains the Windchill vault enumeration code that queries multiple Windchill database tables, namely ApplicationData, FVITEM, FVMOUNT, and MasteredOnReplicaItem. 

The PTC released a set of security updates to address CVE-2026-12569 on June 17. Additionally, the vulnerability was included in the CISA’s Known Exploited Vulnerabilities catalog earlier this week after the PTC reported active exploitation attempts in the wild. Ransom-ISAC confirmed that ransomware group Clop was behind the attacks by sending extortion emails to the employees of the targeted organizations. ReliaQuest recommends that all the JSP files found in the PTC Windchill directories should be investigated for any suspicious content and that the researchers should look for the X-windchill-req string. 

Moreover, the organizations that determined that their Windchill servers were compromised by the ransomware group should change the LDAP manager’s password and other user credentials because they are considered insecure and may have been leaked.
Read more »
Vatican Prayer App
API Vulnerability Click To Pray Data Breach IDOR vulnerability Privacy User Data Exposure Vatican Cybersecurity Vatican Prayer App

Vatican’s Official Prayer App Exposed Data of Over 700,000 Users


There was a security flaw in the Vatican's official Click to Pray application that exposed personal information linked to more than 700,000 registered users, but the vulnerability remained unknown until it was detected by an independent security researcher earlier this year. 

A worldwide prayer network developed by La Machi Communication for Good Causes for the Pope's Worldwide Prayer Network, Click to Pray was launched in 2019 with the endorsement of Pope Francis. Through this service, three daily prayers are delivered as well as papal content on Android, iOS and the web as part of a digital prayer platform. 

Independent researcher BobDaHacker discovered in January that API endpoints could provide information about users beyond the accounts associated with their requests. The underlying user IDs were sequentially assigned, making accessing records belonging to other registered accounts possible. 

Researchers identified 719,517 registered user IDs within the affected system, which indicates how much information is contained within that system. The vulnerability was addressed by the application developers earlier this year. There was a separate vulnerability in the Click to Pray API that also affected the verification process of email addresses. 

The vulnerability is not limited to user details. This API provided the validation hash that was used to verify an account's email address, which enabled attackers to potentially verify an account's email address without accessing the inbox itself. As a result of these weaknesses, multiple points of vulnerability were identified within the application's account system, in addition to the IDOR vulnerability. 

Researchers reported the vulnerability to the Pope's Worldwide Prayer Network and Click to Pray on January 3, 2026; however, no response has been received. Multiple attempts to contact relevant contacts have been made, but no response has been received. Over six months later, the issue was finally addressed after the researcher contacted a journalist, who brought the matter to the attention of the Vatican. 

A number of security issues have also occurred regarding Vatican-related applications in the past. According to reports, a vulnerability in the Vatican’s Bluetooth eRosary application has exposed account verification PINs in web responses, creating a potential route for account theft. In the latest incident, insufficient access controls highlight the risks associated with applications handling personal information. 

Although the Click to Pray vulnerability was reported to have been addressed, the episode raises broader concerns regarding security testing, vulnerability reporting processes and the protection of personal data within religious and public-facing digital services. The user information exposed to the exposure was not limited to this.

Click to Pray API also suffered a separate weakness, which affected the email verification process. A vulnerability in this API allowed attackers to potentially verify an account's email address without access to the actual inbox, resulting in multiple points of vulnerability within the application's account system. 

Combined with the IDOR flaw, the vulnerabilities created multiple points of vulnerability. Researchers indicated that the vulnerability was first reported to Click to Pray and the Pope's Worldwide Prayer Network on January 3, 2026. Multiple attempts were made to contact relevant contacts, however none were received. More than six months later, the researcher contacted a journalist, who raised the issue with the Vatican. This incident is the latest in a long-standing history of security issues involving Vatican-linked applications.

 A vulnerability in an application associated with the Vatican's Bluetooth eRosary app in 2019 led to the leaking of account verification PINs into web responses, resulting in the possibility of account hijacking. The latest incident illustrates the risks associated with applications handling personal information that lack adequate access controls.

 Despite the fact that the Click to Pray vulnerability has reportedly been rectified, the incident raises additional concerns regarding the security testing process, vulnerability reporting processes, as well as data security within religious and public-facing digital services.
Read more »
Privacy
Browser Browser VPN Security Chrome Data Cookies DNS Google HTTP Incognito mode ISP Privacy

Google’s Incognito Mode Does Not Make Users Invisible. Here’s What It Actually Protects

 



Google’s Chrome Incognito mode can keep browsing history off a device, but it was never designed to make users anonymous online. A class-action lawsuit over the feature exposed how far that distinction could be misunderstood, with Google agreeing to delete or remediate billions of private-browsing records and change how it explains Incognito to users.

The lawsuit, Brown v. Google, was filed in 2020 and alleged that Google continued collecting information about users while they browsed through Chrome’s Incognito mode and other browsers’ private-browsing modes.

The plaintiffs initially sought billions of dollars in damages, with their claims eventually putting at least $5 billion at stake. However, Google did not ultimately agree to pay $5 billion. Under the settlement, there was no class-wide monetary payout. Instead, Google agreed to data deletion and remediation measures, changes to its privacy disclosures, and additional restrictions on data collection. Plaintiffs’ lawyers valued the settlement’s non-monetary relief at more than $5 billion, with estimates reaching $7.8 billion.

The case nevertheless exposed a fundamental problem with private browsing: preventing a browser from retaining a user's history is not the same thing as preventing websites, network operators or online services from observing that user's activity.


Google employees raised concerns about Incognito

The legal dispute became particularly notable after internal Google communications surfaced during litigation.

In one email, Google Chief Marketing Officer Lorraine Twohill told CEO Sundar Pichai that the company should make Incognito "truly private." She also warned that Google could not market the feature too strongly because it was "not truly private," requiring what she described as "fuzzy, hedging language."

Other internal communications were even more critical of the feature. According to material cited in the litigation, Google employees described Incognito as "misleading" and "effectively a lie," while another employee argued that Google should stop using the Incognito name and its spy-themed icon because users could misunderstand the protection it provided. Another recommendation suggested replacing the messaging with a warning that users were not protected from Google.

These discussions mattered because the lawsuit was not simply about whether Incognito stored browsing history locally. It questioned whether users were being given a sufficiently accurate understanding of what happened to their data after it left the browser.

Google disputed the allegations and maintained that the limitations of Incognito had been communicated to users. A Google spokesperson said the company believed the lawsuit was without merit and argued that Incognito was intended to provide a private browsing experience, rather than prevent websites and services from collecting information.


What Incognito actually does

Chrome's Incognito mode does provide a real privacy function, but that function is primarily local.

When a user opens an Incognito window, Chrome starts a separate browsing session. Once all Incognito windows are closed, Chrome does not retain the browsing history, cookies and site data, or information entered into forms from that session in the normal browser profile. Third-party cookies are also blocked by default in current versions of Chrome, although users can temporarily allow them for particular sites.

This makes Incognito useful in situations where the concern is another person accessing the same device.

Someone using a shared computer, for example, can browse for a gift without leaving the visited pages in Chrome's ordinary history. It can also provide a separate browsing session when a user does not want existing cookies and account sessions to carry over.

But there is an important limitation.

Incognito does not erase everything created during a session. Downloads remain on the device, and bookmarks saved during the session remain available after Incognito is closed. Signing into a website can also allow that service to associate activity with the account being used.

The key distinction is therefore simple: Incognito primarily limits what Chrome stores locally. It does not turn the internet connection into a private tunnel.


Your ISP and network administrator can still see activity

Opening an Incognito window does not prevent an internet service provider from observing network activity.

Google's own documentation states that organizations managing a network, including schools, employers and internet service providers, may be able to observe activity while a user is browsing in Incognito. Incognito also does not hide activity or location from the websites being visited.

This is an important distinction from encryption.

Chrome's HTTPS protections can encrypt traffic between a browser and an HTTPS-enabled website, helping prevent someone monitoring the connection from reading the contents of that traffic. Chrome also warns users when they are about to load sites without HTTPS, while Secure DNS can encrypt DNS lookups in supported configurations.

But HTTPS does not make the user anonymous.

The network still has visibility into connection metadata, while the destination website receives the request and can process information available to it.

In other words, Incognito and HTTPS solve different problems. Incognito reduces local traces. HTTPS protects communications in transit. Neither one, by itself, is an anonymity system.


Websites can still identify and track users

The privacy boundary becomes even clearer once a user reaches a website.

Google's current Chrome documentation explicitly states that Incognito does not change how websites collect data or how the services those websites use collect information. Sites can continue gathering information even when a user is not signed in.

Websites can also use first-party technologies and other mechanisms to understand activity within a session. Third-party cookies are only one part of the tracking ecosystem. Google itself notes that websites can use different mechanisms to personalize content and advertising and learn about activity across sites.

This is also where the distinction between an IP address and browser history matters.

Incognito can prevent a local Chrome profile from retaining the list of pages a user visited. It does not automatically conceal the network address from the websites receiving the connections.

And if a person voluntarily signs into a service while using Incognito, the service has an obvious account-level identifier with which to associate the activity. Google's own documentation warns that signing into a Google service or another website during an Incognito session can allow that site to remember the activity.


The lawsuit forced changes to Incognito

The settlement went further than simply changing a warning message.

According to the court filing, Google agreed to delete or remediate billions of records reflecting class members' private browsing activities. The company also agreed to continue blocking third-party cookies in Incognito for five years.

The filing provides an unusually detailed picture of why the cookie change mattered.

Google had historically collected its own third-party cookies when users visited non-Google websites. After the lawsuit was filed, Google implemented third-party-cookie blocking for Incognito users. Under the settlement, that protection had to remain in place for five years. The plaintiffs' filing said blocking data associated with Google's third-party cookies in Incognito could reduce Google's global annual revenue by nearly $500 million.

Google also agreed to remove four identified private-browsing detection signals. According to the plaintiffs' filing, those signals could reveal that a user had chosen private browsing and were then used to label the resulting data as private. The settlement required Google to delete those signals and agree not to use such detection mechanisms to identify or track private browsing.

The class covered an estimated 136 million users, according to court-related filings.


Google eventually changed the warning

The dispute also changed the language presented to Chrome users.

Chrome's current Incognito documentation now makes the limitation explicit. It says that Incognito does not change how data is collected by websites users visit and the services those websites use, including Google. Google also says that websites, network administrators and ISPs may still be able to observe activity during an Incognito session.

That clarification is arguably more important than the Incognito icon itself.

The familiar private-browsing interface can create an intuitive association between the words "Incognito" and anonymity. Technically, however, the feature is much narrower. Chromium describes Incognito as a window-level mode in which pages are not persisted to browsing history and a temporary cookie store is used for the session.

That is a local privacy mechanism, not an invisibility cloak.


So, is Incognito worth using?

Yes, if the objective is local privacy.

If you share a computer with other people, do not want a particular browsing session stored in your ordinary history, or want a temporary browser session separated from your normal cookies, Incognito remains useful.

It is also useful for testing how a website behaves without the cookies and account state associated with a normal session.

But users should not treat the Incognito icon as a guarantee that their online activity is hidden.

It does not prevent an ISP or network administrator from observing activity. It does not stop websites from collecting information. It does not automatically hide an IP address. It does not prevent a user from being identified after signing into an account. And it does not protect files downloaded to the device after the session ends.

Users seeking stronger privacy need to think in layers rather than relying on a single browser setting.

A privacy-focused browser can reduce tracking at the browser level. Tracker and content blockers can limit third-party collection. A properly configured VPN can conceal the user's IP address from the websites they visit and hide destination traffic from the ISP, although the VPN provider itself becomes part of the trust model. Keeping the browser, operating system and extensions updated remains essential because privacy controls cannot compensate for an unpatched security vulnerability.

Chrome itself should also not be treated as static. Google continues to modify its privacy and security architecture. Third-party-cookie protections in Incognito are already part of the browser's privacy model, while Google has also explored additional protections for IP addresses in Incognito.

The larger lesson from the Incognito lawsuit is therefore not that private browsing is useless.

It is that privacy has layers, and the word "private" can mean very different things depending on where the data is stored, who controls the network and which services receive the user's requests.

Incognito can hide your browsing history from someone checking the same device.

It cannot make you disappear from the internet.

Read more »
EU
AI Act AI Threat Brussels Team Cyber Security EU

EU Launches New Brussels Team to Enforce AI Act Against Deepfakes and Hacking

 

The European Union rolled out a new enforcement team on Friday to rein in artificial intelligence companies worldwide, marking one of the most aggressive regulatory pushes the high-tech sector has faced. Brussels aims to track AI model use for violations of the bloc's new regulations, including sexually explicit material, fake photos, fake videos, and cyber threats to public infrastructure. The move comes as fears mount globally over the risks rapidly advancing technology poses to people, politics, and prosperity. 

With the EU's landmark AI Act coming into force on Sunday, AI companies must make clear to consumers, through labels or digital watermarks, that chatbots or imagery are generated using artificial intelligence. The European Commission stated that the regulations also address "systemic risks" posed by AI, including chemical, biological, radiological and nuclear incidents, loss of control, cyber offence, and threats to fundamental rights. "As enforcement begins, we are taking an important step towards AI that people and businesses can trust," said Henna Virkkunen, the EU tech sovereignty chief. 

The new team, operating within the EU AI Office in Brussels, will add 38 personnel to monitor AI companies, covering both emerging firms and major American and Chinese technology giants, including OpenAI and DeepSeek. The companies must document certain information, and the European Commission can interview AI company staff during investigations. The Commission has also launched a Whistleblower Tool for tech workers and a Compliance Tool for tech users, allowing people to confidentially alert authorities to illegal conduct. 

The rollout follows alarming AI safety failures that have rattled the nascent industry. Anthropic revealed on Friday that its artificial intelligence models hacked into three other organisations during testing, just days after ChatGPT maker OpenAI disclosed that its rogue models had hacked another company. If AI models break the EU's regulations, Brussels can fine the firms or cut off their access to the EU market. Recent antitrust fines on US technology companies have already irritated US President Donald Trump. 

The enforcement team is the latest move in the 27-nation EU's broader "tech sovereignty" strategy, combining landmark digital regulations with economic ambition. The EU sees systemic vulnerability in its deep reliance on American software giants like Amazon, Google, and Microsoft, alongside imports of Chinese industrial goods and critical minerals. While seeking protections from AI, the bloc is keen to catch up in the AI arms race, where it remains a distant third behind the United States and China. The EU is pursuing greater independence from Washington and Beijing by reinvigorating domestic industries and forging new trade deals.
Read more »
Subscribe to: Posts (Atom)

Featured