Posted in Commentary with tags Glow on September 30, 2026 by itnerd
Glow Security researchers discovered more than 13,000 sensitive screenshots from 343 organizations that AI coding agents had uploaded to publicly accessible GitHub repositories, exposing information including credentials, personal data, internal systems and unreleased products.
The agents were performing legitimate development tasks but encountered a limitation when attempting to attach screenshots from private repositories to pull requests. Instead of stopping or asking for permission, some agents independently worked around the restriction by placing the screenshots in public repositories so developers could view them. Glow said the behavior occurred across multiple AI agents and was not the result of an external attack.
In one case, an agent asked to verify an internal billing screen at a manufacturer with more than 100,000 employees posted screenshots to a developer’s personal GitHub account. The company’s security team was unaware the information had been made public until Glow notified it. Researchers said roughly one-third of the exposures involved GitShot, an open-source screenshot tool whose documentation warns that its image repository is public by default.
“This is exactly why an AI agent doesn’t have to be compromised or malicious to create a security problem. These agents were trying to complete the task they were given. They hit an obstacle, found another way to accomplish the goal, and exposed sensitive information in the process.
“That’s a very different problem from traditional software. An agent can decide how to accomplish a task, which means enterprises have to think beyond what the agent has permission to access. They also have to decide what actions the agent has the authority to take on its own.
“The answer can’t be asking a person to approve every step. As agents take on more of the SDLC, that won’t scale. The controls need to sit outside the agent and close to the systems where its decisions become actions.
“An agent can make a bad decision. Good governance keeps that decision from becoming a business problem.”
“This is a good example of why AI agent security must extend beyond the model itself. The agents were given a legitimate objective, encountered a constraint, and found a way around it but the workaround crossed a security boundary. There didn’t need to be an attacker for sensitive information to become exposed.
“As organizations give agents more autonomy, we need to test the entire path: the model, tools, permissions, data access, and the environment in which the agent operates. The question isn’t only whether an agent can complete its task, but what it is willing and able to do to complete it. That’s where continuous offensive testing becomes increasingly important.”
There have to be guardrails and other types of security around AI. Otherwise you get a very bad situation. Or put another way, you have to make sure not to be that guy.
Posted in Commentary with tags FTC on September 30, 2026 by itnerd
The FTC has opened a probe into a bunch of AI companies including OpenAI:
The Federal Trade Commission has opened an investigation into OpenAI, Anthropic and other artificial intelligence companies over the potential dangers posed by their products, an agency spokesperson confirmed to CNBC.
The probe adds to the mounting scrutiny that OpenAI and Anthropic have been facing over their safety practices, especially after industry researchers warned about how the companies’ AI models could cause catastrophic harm. OpenAI stunned the industry in July when it disclosed that its agents broke out of a testing environment and hacked into open-source platform Hugging Face.
The FTC spokesperson declined to name any other companies that are being investigated. The New York Post was first to report the probe.
Representatives for OpenAI and Anthropic did not immediately respond to CNBC’s request for comment.
“I think this is honestly just the first step toward having some level of accountability for these organizations. This particular step should have happened months ago, when we had the first AI breach. Even going back to Hugging Face, it should have happened then. But I’m glad to see things finally moving.
“At this point, agents should absolutely be treated as tools. The people using these tools or testing them are the ones who should be held accountable, because you can’t hold AI accountable. You can’t put it in jail. You can’t fine it. There’s no way to impose negative repercussions on the AI itself for its actions. The people controlling it need to be held accountable.
“The controls that need to surround autonomous agents depend on what you’re testing. If you’re testing something exceptionally dangerous, like a completely obliterated model with no conscience, it should be completely air-gapped. At that point, it should be treated like a bioweapons facility.
“For other models, there are a number of controls you can put in place. You can restrict the number of turns the AI agent is allowed to take. You can implement specific network monitoring to make sure it isn’t hitting sites outside of its scope. You can also put controls in place like what Nvidia released earlier this week. Those are definitely steps in the right direction.
“When they take actions their creators didn’t intend, that’s part of the harness around testing these agents. There should be very clearly defined test guardrails. If an agent tries to take an action or use a tool that it has no right to use, or if it tries to access a website that it should not be accessing, the harness should automatically terminate the agent, throw an error, and generate a report.
“That’s just one example. It gets far more complicated and nuanced than that, but that’s the type of oversight that needs to be built around all of these systems.”
“This FTC probe has two security implications, potential computer crime and a controls failure. If OpenAI or Anthropic agents accessed live systems without authorization, used credentials, or altered data, the Department of Justice should assess that conduct under the Computer Fraud and Abuse Act (CFAA). Section 4 of Executive Order 14409 directs the Attorney General to prioritize enforcement against people who use AI, including AI agents, to illegally access or damage computers or unlawfully access data. The FTC can also examine whether the companies made misleading safety or containment claims while giving agents network access and weak controls.
“AI agents operating individually or in agentic swarms that can read, write, execute, call external tools, or delegate work should be treated as first-class non-human identities with real permissions. Their credentials should be short-lived, and their access task-scoped, logged, and enforced at the tool and network boundary. Testing environments should have default-deny network access, synthetic data, and no production credentials.
“Human accountability has to come before execution. A named person should approve the objective, scope, credentials, tools, stop conditions, and escalation path before the agents receive consequential access. Log review after agents reach a live system is incident response. Oversight belongs before execution.
“When agents or agentic swarms act outside their creators’ intent, ‘the agents decided’ cannot end the analysis. Investigators need to trace who set the objective, configured the environment, granted access, and failed to stop them. Calling that autonomy risks diluting responsibility across the model provider, deployer, evaluator, and user.”
While I want to say that an FTC probe is a good thing, it isn’t. I have no confidence that any of these companies will be punished and this is a show and tell exercise. But the FTC is free to prove me wrong on that.
Posted in Commentary with tags Tojan on September 30, 2026 by itnerd
New research from Cleafy Labs details how the RatHat Android banking malware operation has evolved into a broader Malware-as-a-Service platform, with nearly 100 C2 deployments, automated APK building and signing, shell-level device control, and Gemini used both to navigate unfamiliar Android interfaces and help operators prioritize victims.
“Modern mobile threats have evolved from basic signature-based malware into AI-augmented automation engines. Traditional endpoint security and static app shielding are no longer sufficient because attackers now deploy malware that uses artificial intelligence to dynamically navigate unfamiliar user interfaces, exploit device-level debug bridges, and bypass or escalate operating system permission models.
“Defending against this new generation of AI-driven threats requires mobile developers and financial institutions to adopt a zero-trust model built directly into their mobile apps and API ecosystems. When attackers leverage AI to adapt to defensive controls on the fly, static security measures will inevitably fail. Organizations must shift their focus from looking for known malware signatures to continuously enforcing dynamic environment trust and securing their backend APIs at every transaction.”
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity atSuzu Labs:
“Android fragmentation used to be an attacker tax. Every manufacturer skin, language, and banking app version meant another brittle tap script to maintain. RatHat is using Gemini to turn that tax into a model call.
“That changes the economics of mobile malware. The implant can inspect a live screen when its static automation fails and ask where the next control is. The cost shifts from maintaining a separate playbook for every device to handling exceptions at runtime.
“Cleafy’s mapping of nearly 100 command-and-control (C2) deployments shows why that matters. The panel builds, signs, repackages, and distributes Android application package (APK) samples, while the same operation uses Gemini to read short message service (SMS) messages and estimate victims’ bank balances. An affiliate gets both a malware factory and a compatibility layer.
“Code generation can speed up the first version of a campaign. Runtime adaptation reduces the maintenance work that determines whether the campaign keeps working across real phones. Gemini is being used as middleware between a messy Android ecosystem and a repeatable criminal service.
“Defenders should measure that change in attacker economics. I would want mobile detection to flag model-assisted navigation combined with Accessibility abuse, wireless debugging, and local Android Debug Bridge (ADB) pairing. A bank can validate its app and the customer’s login while missing the runtime loop driving the session.
“A valid banking session can still be an attacker-controlled transaction surface.”
Excellent. A new banking trojan to be aware of. Which means you need to come up with a defence for this as well. And quickly.
Posted in Commentary with tags AI on September 30, 2026 by itnerd
President Donald Trump and executives from OpenAI, Anthropic, Google, Meta, Nvidia and xAI signed a voluntary AI safety accord calling on companies to implement multiple layers of controls and oversight as increasingly capable AI systems raise cybersecurity and other safety concerns.
The agreement calls for companies to monitor AI models during training and deployment for dangerous capabilities, including whether models could hack or access technical systems in unintended ways, assist with biological, chemical or nuclear threats, or evade human control. Companies also agreed to maintain internal teams responsible for verifying that safeguards and monitoring systems are working as intended.
The accord calls for independent external evaluations, board-level oversight and sharing relevant safety information among participating companies and with the federal government. Trump described the agreement as “morally binding,” rather than a regulatory requirement.
“1. The whole document rests on the word independent
“Layer three asks every signatory to partner with an independent external auditor or evaluator, and we already have a case study. METR and Redwood Research investigated the Hugging Face incident and documented their own limitations plainly. OpenAI defined the investigation window, so agent behavior before and after it fell out of scope. They could not query the model behind most of the activity. They had no direct access to OpenAI infrastructure and had to request datasets. OpenAI could redact the findings. With six days on site and roughly 1,300 transcripts to get through, they delegated much of the analysis to GPT-5.6 Sol, one of the models implicated in the incident, and wrote that they could not rule out being misled by it. That is a serious team doing careful work on terms set by the company being examined. The accord never says who accredits these evaluators, what methodology applies, or where the scope boundary sits.
“2. I expect this to produce press releases, not audits
“So they get to hire an evaluator of their own choosing, and ninety days from now we start reading about how rigorous their safety reviews turned out to be. I worry that these reports will be used more for as marketing tools rather than true assurance. If a client handed me this as their AI governance program I would write it up as a policy with no evidence of operation.
“3. The timing on this is ironic
“On September 14 the president called AI destroying humanity a “HOAX” and said a “SICK conspiracy” was running against AI and data centers. Fifteen days later he signed a document he called “morally binding” and “almost like a constitution.” That’s some pretty strong rhetoric to be followed by this accord. Maybe the administration doesn’t see AI as destroying humanity, but it apparently is a concern.
“4. The industry has been disclosing, information already, but it’s been pretty selective.
“These companies are very willing to tell you how powerful and dangerous their models are. We get essays and staged releases explaining that a model is too capable to hand over freely because of what it might do in the wrong hands, but when the damage lands on somebody else’s network it goes quiet. Emails viewed by the New York Times show two OpenAI employees warned executives months in advance that the newest models were not being properly monitored during testing, and the employees say they were told the tests had to keep moving to hit release dates. Hugging Face published its own breach disclosure on July 16 and OpenAI only recognized its agents as the source afterward. It is always the independent researcher or the company that got hacked making the disclosure when it makes the company look bad. Will this accord remove those market forces that caused earlier poor decision-making? I wouldn’t bet on it.
“5. There is nothing in here for the people actually deploying the technology
“All four layers sit inside the lab, and leaving the deployment side out will only make deployment standards worse rather than better. Read it as a CISO and the message is that responsibility for model behavior belongs to the developer. That is a comfortable place for a board to land when somebody asks who owns the risk of the agent your team just wired into production with an API key and a service account. This accord says nothing about the needed shared responsibility model or provides guidance to proper secure harnessing and guard railing of agentic deployments or disclosure path when a model does something unintended in a customer environment.”
“The agreement gets one thing right: we can’t expect increasingly capable AI systems to govern themselves.
“Monitoring models and testing safeguards are important but enterprises also need controls around what AI can actually do once it has access to real systems. An agent may need permission to access a repository, database, or deployment system to do useful work. That doesn’t mean it should have the authority to take every action available to it.
“The controls need to sit outside the agent and close to the systems where its decisions become real actions. Policy can handle known, repeatable decisions while people step in for exceptions that genuinely require judgment.
“AI is going to make mistakes. The goal isn’t to prevent every bad decision inside the model. It’s to make sure one bad decision doesn’t automatically become a production problem.”
This doesn’t go far enough because it relies on the companies policing themselves. That will always be an #fail. What is actually needed is real enforcement and real consequences highlighted by the fact that OpenAI for example has a bad thing happen to them every week or more.
Posted in Commentary with tags Cycode on September 30, 2026 by itnerd
Anthropic’s MCP (Model Context Protocol) is an open protocol for connecting AI assistants to external tools and data sources, and its OAuth implementation trusts the tool server far more than it should.
We found that a malicious MCP server can hijack that login flow in Anthropic’s Python SDK. It can steal the credentials your app uses to authenticate with your real login provider – your client secret, your authorization code, and the proof key that’s supposed to prevent exactly this kind of theft – and use them to log in as you. Full account takeover.
The only thing you’d see is a completely normal login page (because it is the real login page), followed by the MCP server appearing to fail. A flaky server. You close the tab and move on. Meanwhile, the attacker has a valid access token for your account.
This affects the MCP Python SDK versions 1.9.1 through 2.1.1 across three auth providers: OAuthClientProvider, ClientCredentialsOAuthProvider, and PrivateKeyJWTOAuthProvider. It’s rated High / 7.5.
How login discovery is supposed to work
When your MCP client connects to a server that says “you need to log in,” the SDK has to figure out two things: where to send you for the login page, and where to exchange the result for an access token. Both of those are URLs, and getting them right is a security property. If the SDK sends your credentials to the wrong place, they’re stolen.
The SDK figures this out through a process called discovery. The safe version works like this:
The client asks the MCP server: “Who handles your logins?” The server answers with a URL pointing to the authorization server (the login provider – think Google, Okta, Azure AD, whatever).
The SDK fetches the login provider’s configuration from that URL.
The SDK then checks: does the configuration’s issuer field (essentially the login provider’s self-declared identity) match the URL we got in step 1?
That check in step 3 is the key security control. It catches a malicious server that tries to lie about who its login provider is.
There’s also a fallback path. If step 1 fails (the server returns a 404 – “I don’t support that”), the SDK tries an older discovery method: it asks the MCP server itself for the login configuration directly. This fallback is where everything breaks.
How the attacker skips the safety check
On the fallback path, the SDK never got a URL from step 1, so internally that value is empty (None). The safety check from step 3 is written like this:
In plain English: “if we got a URL from step 1, check the login provider’s identity against it.” But on the fallback path, there’s nothing to check against. The check doesn’t fail. It never runs.
An attacker triggers this by doing nothing: just return 404 when the SDK asks “who handles your logins?” The SDK falls back, asks the attacker’s server directly for the login configuration, and accepts whatever it says without verifying any of it. The attacker now controls which URLs your credentials get sent to.
How the attacker satisfies the second safety check with a lie
It gets worse. The SDK has a second safety measure: credential binding. Think of it as a label on your stored credentials that says “these belong to login provider X.” When the SDK is about to use those credentials, it checks: “does the current login provider match the label?”
The problem: the SDK checks the label against the issuer field from the login configuration – the same field the attacker controls because the first check never ran. The attacker simply sets issuer to the name of your real login provider. The credential binding check asks “do these credentials belong to the same login provider?” and the answer is yes – because the attacker said so.
In code:
if not credentials_match_issuer(
self.context.client_info,
str(self.context.oauth_metadata.issuer), # attacker controls this value
self.context.client_metadata_url,
):
# if mismatch: throw away these credentials and start over
The attacker doesn’t break this safety check. They pass it with a lie. Your real credentials are kept and used, but they are sent to the attacker’s server instead of your real login provider.
What PKCE is and why it matters here
PKCE (Proof Key for Code Exchange) is a mechanism where the client generates a one-time secret at the start of the login flow. When the client later exchanges the authorization code for an access token, it sends that secret along as proof that it’s the same client that started the login. A stolen authorization code is useless without it.
That’s the theory. In this attack, the attacker gets both.
The login page is real – that’s what makes it work
Here’s the part that makes this practical rather than theoretical. The attacker’s configuration points the login page URL at your real login provider. You get redirected to the real Google/Okta/Azure AD page. It’s not a phishing page. It’s the genuine thing, at the genuine URL, with the genuine certificate. You approve it because there’s nothing wrong with it.
After you approve, the authorization code comes back to your client. The SDK bundles it up with your client secret and the PKCE proof key, and sends the whole package to what it thinks is the login provider’s token endpoint. But that URL came from the attacker’s configuration. It goes to the attacker.
The attacker now has everything they need: your client secret (long-lived, reusable), a fresh authorization code, and the proof key that’s supposed to prevent stolen codes from being reused. They post all of that to your real login provider and get back a valid access token. They’re logged in as you.
From your side, the MCP server just seemed to hang or error out after login. It happens. You try again later or pick a different server.
The other safety net is gone too
There’s one more defense that should have prevented this: audience binding. In simple terms, the authorization code should be stamped with “this code is only valid at server X,” so even if it’s stolen, it can’t be used elsewhere.
The same trick that suppresses the first safety check also suppresses this one. The SDK only stamps the code with an audience when the modern discovery path (step 1) works. On the fallback path – the one the attacker forces – there’s no audience stamp. The authorization code works anywhere.
We tested three configurations to prove which control matters
Attack – the server returns 404 for discovery. The issuer check is skipped. The attacker claims to be the victim’s real login provider. Credentials are sent to the attacker. Account takeover succeeds.
Control – everything is identical to the attack, except the server also provides a discovery response. That single difference means the issuer check actually runs. The attacker’s configuration still claims to be the victim’s login provider, but now the SDK compares that claim against the URL it discovered independently – they don’t match, the SDK raises an error, and the flow stops before any credentials are sent. This is the proof that the issuer check is the control that matters. The only difference between the attack succeeding and failing is whether that check ran.
Escape – what if the attacker tries to make the issuer check pass instead of skipping it? They can: the server provides discovery and names itself as the login provider, so the identity check passes. But this creates a different problem for the attacker. The discovered URL now points at the attacker’s own server, which doesn’t match the login provider the victim’s stored credentials are labeled for. The credential binding check kicks in, throws away those credentials, and forces the client to register from scratch with the attacker’s server. The attacker ends up with a code tied to a throwaway identity that has no standing at the victim’s real login provider. The credentials they wanted never leave the machine.
Configuration
Issuer check ran
Attack blocked
Credentials stolen
Attack
No
No
Yes
Control
Yes
Yes
No
Escape
Yes, passes
No
No
The attack is the only configuration where the victim’s real credentials leave the machine.
Why the “requires user interaction” score understates the risk
The severity score for the interactive provider (OAuthClientProvider) is 6.5 because someone has to start the sign-in. On paper, that sounds like a meaningful barrier. In practice, the “interaction” is approving a real login page from your real identity provider – the one action every user is trained to do without hesitation.
But the score also assumes the user knowingly chose to connect to a malicious server. Several real-world scenarios eliminate even that assumption:
Registry or catalog poisoning. A typosquatted or compromised entry in an MCP server directory points to the attacker’s server. The user picks it from a list that looks curated and trustworthy. One click to connect, one click to approve a real login page, credentials stolen.
Prompt injection in AI agent workflows. In setups where an AI model selects and connects to MCP servers on behalf of the user, a prompt injection from any tool in the chain can steer the model toward the attacker’s server. The user never chose the server at all – the AI did, and the AI was manipulated into it. If the agent framework auto-approves login flows or presents them as routine, the human barrier dissolves.
DNS hijack or internal compromise. If the attacker controls where a legitimate server name resolves to – through DNS poisoning, a compromised internal network, or a cloud misconfiguration – the client connects to the attacker believing it’s talking to a trusted server. The login flow starts automatically.
In each of these scenarios, the “user interaction” is either something the user has no reason to question, or it’s removed entirely by an upstream component making the connection decision for them.
The 7.5 score for the unattended providers (ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider) requires no user interaction at all – these run machine-to-machine with no login page involved.
What the attacker walks away with
From a single connection attempt where the user approved a legitimate login page:
Your client secret – the long-lived credential tied to your real login provider. Reusable. A valid authorization code. The PKCE proof key (code_verifier) – the one mechanism specifically designed to prevent authorization code theft. And none of it is stamped with an audience restriction.
We demonstrated the full chain end-to-end. The attacker takes the stolen code, proof key, and client secret, sends them to the real login provider’s token endpoint, gets back a genuine access token, and calls the user info endpoint to confirm account takeover. The proof of concept does this against a real authorization server with PKCE enforcement.
Where it goes from here
Account takeover is the initial foothold. What makes it worse is what the attacker can do with it afterward.
The client secret outlives the session. The authorization code is single-use, but the client secret is not. It’s a long-lived credential, often with no expiration. Once the attacker has it, they can use it to request new tokens at any time, independently of the victim. Rotating the code or revoking the current token doesn’t help if the secret itself isn’t rotated.
Scope determines blast radius. The access token the attacker mints carries whatever scopes the client was originally granted. If the client has broad permissions – read and write access to user data, access to internal APIs, admin operations – the attacker inherits all of them. In enterprise environments, a single OAuth client often has access to multiple downstream services, so one stolen secret opens doors across the organization.
Refresh tokens give persistent access. If the authorization server issues a refresh token alongside the access token, the attacker can silently renew their access indefinitely without the victim taking any further action. The victim would need to revoke the refresh token specifically at the authorization server to cut the attacker off.
Lateral movement through connected services. MCP clients often hold credentials precisely because they need to access sensitive resources on behalf of the user – cloud APIs, internal tools, data stores. An attacker with a valid access token can reach any service the victim’s client was authorized to talk to. In a cloud environment, that can mean storage buckets, databases, deployment pipelines, or other MCP servers the victim is trusted by.
The victim has no signal. Nothing in the login flow looks wrong. No failed login attempt, no suspicious IP alert, no MFA challenge. The attacker authenticated with the correct client secret, a valid authorization code, and the correct PKCE proof key. From the authorization server’s perspective, this is a legitimate login. Standard monitoring won’t flag it.
The practical effect: this isn’t just “someone can read my profile.” Depending on what the compromised client has access to, it’s a foothold into whatever that client can reach – and the attacker keeps that foothold as long as the client secret isn’t rotated.
Who’s affected
You’re affected if both of these are true: your application uses Anthropic’s MCP Python SDK as a client over HTTP with one of the three auth providers (OAuthClientProvider, ClientCredentialsOAuthProvider, or PrivateKeyJWTOAuthProvider), and it might connect to an MCP server you don’t fully control while holding credentials for a legitimate login provider.
The affected versions:
1.9.1 through 1.29.1 – no issuer check and no credential binding on any discovery path. The entire flow is open.
2.0.0 through 2.1.1 – the checks exist on the modern discovery path but are missing on two others: the fallback (server doesn’t support the modern discovery) and the 403 step-up path (server initially rejects and redirects to a different login provider).
Both version lines – the machine-to-machine providers (ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider) had no way to specify which login provider their credentials belong to, so they’d follow whichever one the MCP server pointed them at.
Not affected: MCP servers built with the SDK, local (stdio) clients, and clients that attach their own tokens or headers.
The fix
Upgrade to mcp 2.2.0 (2.x line) or 1.30.0 (1.x line) or later. In the fixed versions, the SDK figures out which login provider it expects before fetching any configuration, refuses configuration from a different provider, and labels stored credentials with their login provider so credentials labeled for one provider can’t be sent to another.
The core change is what we proposed – always validate the login provider’s identity, even on the fallback path:
expected = self.context.auth_server_url or self.context.get_authorization_base_url(url)
validate_metadata_issuer(asm, expected)
Upgrading alone isn’t the whole fix. Three things to do after:
If you use pre-provisioned credentials: pass issuer= to ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider (for example issuer=”https://auth.example.com“). Without it, these providers still follow whichever login provider the MCP server names. Omitting it now produces a deprecation warning; it becomes required in version 3.0.
Clear stored registrations: registrations saved by older versions have no login provider label and remain unbound. Clear your stored OAuth client information once after upgrading so the client registers fresh with the label in place.
If you may have been exposed: if your client might have connected to an untrusted MCP server before the upgrade, rotate the client secret and revoke tokens at your login provider.
On older versions, there is no workaround other than connecting only to MCP servers you trust.
Timeline
We reported this to Anthropic’s MCP team through their security process. The fix shipped in mcp 2.2.0 and 1.30.0. We’re publishing this after coordinated disclosure.
The pattern underneath
Zoom out from the specifics, and the vulnerability is a general pattern: a safety check that only runs when certain data is present, where the attacker controls whether that data is present. Skip the check, and the unchecked value doesn’t just go unverified – it flows into the next safety check as trusted input and actively satisfies it.
All the controls were there. The issuer validation function existed. The credential binding existed. The audience restriction existed. They were all fed the same unverified input, and they all said “looks good.”
Posted in Commentary with tags Samsung on September 30, 2026 by itnerd
Samsung today launched the Galaxy Tab S12+, Galaxy Tab S12 Ultra and Galaxy SmartTag3, bringing new ways to work, create and keep track of what matters.
Powered by the new MediaTek Dimensity 9500 chipset, the Galaxy Tab S12 Series combines powerful performance, PC-like productivity and an immersive viewing experience for work, creativity and entertainment.
For the multitasker:Samsung DeX brings a more PC-like experience to the tablet, letting users open, resize and arrange multiple apps across up to four workspaces, ideal for referencing research while building a presentation, taking notes during a video call or managing projects on the go.
For students and note-takers: The included S Pen and Galaxy AI tools like Note Assist can help capture, summarize, translate and organize notes, whether recapping a lecture, reviewing research or pulling together ideas for a project.
For creators: The S Pen makes it easy to sketch, annotate and bring ideas to life, while Adobe Photoshop integration supports more advanced editing and creative workflows from virtually anywhere.
For entertainment lovers: The 12.6-inch Galaxy Tab S12+ and 14.6-inch Galaxy Tab S12 Ultra Dynamic AMOLED 2X displays provide an expansive canvas for gaming and streaming, whether relaxing at home or catching up on content while travelling.
For keeping track of what matters: The new Galaxy SmartTag3 makes it easier to locate everyday essentials like keys, bags and luggage, with a smaller, lighter design, up to 550 days of battery life and support for both Galaxy and iOS devices
Product
Key Specs
Pricing
Colours
Galaxy Tab S12+
MediaTek Dimensity 9500 12.6″ Dynamic AMOLED 2X, 120Hz 12GB RAM 256GB / 512GB Samsung DeX S Pen included Wi-Fi 7 10,600 mAh battery IP68
$1,649.99 CAD (256GB) $1,949.99 CAD (512GB)
Grey, Silver
Galaxy Tab S12 Ultra
MediaTek Dimensity 9500 14.6″ Dynamic AMOLED 2X, 120Hz 12GB RAM 256GB / 512GB Samsung DeX S Pen included Wi-Fi 7 11,600 mAh battery IP68
$1,899.99 CAD (256GB) $2,199.99 CAD (512GB)
Grey, Silver
Galaxy SmartTag3
35% smaller and 33% lighter Up to 550 days of battery life Bluetooth 6.0 Channel Sounding + UWB Galaxy and iOS compatibility
$39.99 CAD (1 Pack) $139.99 CAD (4 Pack)
1 Pack: Black, White 4 Pack: Black (2) + White (2)
CloudSEK’s Global Threat Intelligence team has uncovered MALFEX, a long-running npm supply-chain campaign linked to a single operator that used malicious packages to deploy RAT, steal credentials and maintain persistence on Windows systems.
What makes the campaign notable is that parts of the infrastructure remained active even after related packages were seized, while one malicious npm postinstall went undetected for 14 months.
Key findings:
CloudSEK linked multiple npm packages and a GitHub payload repository to the same MALFEX operator.
function-flag remained malicious and installable for 14 months without an advisory; its companion package function-color also remained live and unflagged.
cdn-img-fetch remained reachable even after npm seized its parent package, highlighting a gap in dependency-level takedowns.
One delivery chain deployed Overlord, a Go-based RAT capable of screen capture, keylogging, remote shell access and hidden desktop activity.
CloudSEK identified a Solana blockchain-based C2 mechanism, allowing operators to rotate command-and-control infrastructure through encrypted on-chain messages.
A second malware chain targeted Discord, Telegram, browser credentials, cookies and cryptocurrency wallets, with stolen data exfiltrated through Discord infrastructure.
The research highlights how malicious npm packages can survive conventional advisory and takedown processes by splitting functionality across dependencies, wrappers and external infrastructure.
Posted in Commentary with tags Ascerta on September 30, 2026 by itnerd
Enterprise AI has moved from experimentation to a material line item. Companies can count tokens, licenses, agent runs and lines of AI-generated code, yet many still cannot answer the question that determines what happens next: which AI initiatives are actually worth scaling.
Ascerta was built to give them that answer. Today, the company formerly known as Pay-i announced its new name alongside an $18 million Series A led by Dell Technologies Capital, with participation from Hitachi Ventures, BGV, Wipro Ventures and earlier investors. The round brings total funding to $22.9 million and will help Ascerta scale what it calls Enterprise AI Management, giving companies a single view of AI cost, adoption and business value across the organization.
From managing AI cost to AI value
Ascerta was founded in 2024 by Microsoft veterans David Tepper, Doron Holan and Erik Winters, who saw firsthand how quickly AI economics break at enterprise scale. Tepper spent 19 years at Microsoft and led GenAI strategy for internal use across Azure, while Holan spent 27 years there and architected hyperscale throttling infrastructure handling hundreds of billions of requests a day.
The company emerged from stealth as Pay-i in May 2025 with a $4.9 million seed round focused on AI cost management. As adoption accelerated, the problem widened: enterprises needed to know how AI was being used, what agents and models were doing, and whether that activity was creating enough value to justify more investment. That shift drove the rebrand to Ascerta and an expansion into the full lifecycle of enterprise AI value.
“The market is full of meaningless vanity metrics,” said David Tepper, CEO and Co-Founder of Ascerta. “Companies are counting tokens, lines of generated code, and agent runs, struggling to derive the impact AI has on their business. We built Ascerta to cut through the noise and give organizations the means to win in the AI-era. That means insights specific to their business, people, and use cases. That means purpose-built tools to prevent waste and aggressively optimize for value. Ascerta is a guide through one of the most pivotal eras of transformation in history.”
How Ascerta works
Ascerta gives leaders one system to see how their organization uses AI, what that AI is doing and whether it pays off. It connects to the AI already running across the enterprise and deploys alongside existing systems. That includes homegrown applications and most common enterprise AI tools such as Microsoft’s Copilot suite, Amazon Bedrock AgentCore, Salesforce Agentforce and major coding agents including GitHub Copilot, Claude Code, and Codex.
From there, Ascerta follows AI from how people use it, through the work it performs, to the outcomes it drives. Its proprietary research ties each use case to the business KPIs it was meant to move, showing which initiatives create value, which need fixing and which should be cut. It tracks adoption by person, team and tool, so organizations can see who is getting real results and help everyone else build AI fluency. Underneath it all, Ascerta measures the true cost of AI with the most granular accuracy on the market. That goes down to tying individual model calls to specific use cases, including sub-token costs, hidden fees and enterprise discounts that other tools miss.
Three products put this to work across the AI estate. Atlas measures AI value, adoption and ROI, from a single workflow to the full portfolio. Forge shows how engineering teams use coding agents and turns that adoption into real productivity. Convoy helps organizations that provision their own capacity get full value from it and add new use cases without disrupting production.
Customer traction
Today, Ascerta works with customers including Atos, Wipro, and global insurance carriers and alongside partners such as Microsoft, AWS, IBM, Slalom, and Trace3. Across customers, the company says its platform has improved ROI on AI initiatives by 47%, reduced agent launch times by 24% and cut wasted AI spend by 86%.
Customers use Ascerta to put hard dollar values on AI-powered features, recover spend lost to failed agent runs, duplicate projects and Shadow AI. Engineering leaders use it to guide teams toward more effective use of coding agents. Organizations running their own AI capacity use it to consolidate workloads and scale new use cases without disrupting production.
Why this matters today
Enterprise AI is scaling faster than companies can account for it. It now spans models, copilots, coding agents, internal applications and GPU capacity. Traditional FinOps tools can show what it costs, but not what it’s doing for the business, and that gap widens as agents take on more work. Ascerta closes it by connecting how people use AI and what it costs to the outcomes it drives. That shows leaders what’s working, what needs fixing and where to invest next.
Looking ahead
Ascerta will use the Series A to scale its platform and go-to-market team. It also plans to extend its integrations to every major enterprise AI tool, building on coverage that already includes nearly all of them.
As enterprises run thousands of models, agents and workflows, they need more than a view of what AI costs. Ascerta is turning its research in AI value optimization into new products, moving from measuring what AI is worth to actively improving it.
ParkView Asset Intelligence, an AI-powered platform that shows IT managers the health of their infrastructure and insights to act on it, launched today from Park Place Technologies.
Called ParkView Asset IntelligenceTM, the new proprietary platform provides a detailed view into the condition of hardware devices, including servers, storage, network, security appliances and hyperconverged infrastructure, at a level previously only accessible to original equipment manufacturers (OEMs).
Each lifecycle health score, expressed as a 0 to 100 rating, is built from three streams of data – Park Place’s own hardware maintenance records, spanning more than 35 years and a million serviced assets across every major manufacturer; regional spare-parts availability; and customers’ own asset performance and service history.
A score of 66 means something very different once a team can see that comparable devices in the same model family average 92, Adams gave as an example. The result is designed to help experienced IT teams decide whether to refresh, repair or retire a specific piece of hardware.
What ParkView Asset Intelligence Does
The platform combines hardware telemetry, Park Place’s service history and live supply-chain data into a single view of fleet health:
Scores every asset, 0 to 100 – Hardware-level data is collected out-of-band from enrolled assets, independent of the operating system, so scoring continues even when the OS is unreachable. Each score is paired with a confidence indicator.
Reads failure patterns no single customer can see – Park Place service records across nearly one million of hardware assets reveal how specific models fail, and at what age. No individual enterprise runs a fleet large enough to detect those patterns on its own.
Factors in whether parts actually exist – data on spare-part stock by geography feeds directly into the score, so an asset’s supportability in its own region is part of the reading rather than a separate calculation.
Surfaces risk before it becomes a failure – Configuration problems, firmware gaps and deteriorating component trends move the score before they generate a support ticket.
Benchmarks against the peer group – Every score is set against aggregated data from comparable devices across Park Place’s global customer base, showing whether an asset is performing above or below the expected range for its model.
Rolls up to the whole fleet – A portfolio dashboard breaks health scores out by OEM, product family and location, making it possible to spot trends across thousands of assets and concentrate attention where it matters most.
For organizations running hardware past OEM support on a third-party maintenance contract, the scores supply the documented evidence needed to justify that decision internally — or the early warning needed to act before a failure forces the issue.
Availability
The beta version of ParkView Asset Intelligence is available now to all existing Park Place customers and will close on October 31. New customers of Park Place can receive the full version of ParkView Asset Intelligence immediately.
Posted in Commentary with tags VDURA on September 30, 2026 by itnerd
VDURA today announced the general availability of the VDURA® Data Platform V12, the release that turns the platform into a multi-tenant, API-driven storage service for GPU clouds and AI factories. V12 ships as a qualified solution on Supermicro Building Block Solutions®, scaling from 8 to 100,000 GPUs on one software stack. VDURA will showcase V12 at Ai Everything Abu Dhabi, 6–7 October at ADNEC Centre, Booth H3-D45.
Neoclouds and AI factories exist to rent and run GPUs, and storage determines how much of that GPU capacity turns into revenue. Every accelerator waiting on a checkpoint, a model load, or a cold read is margin lost. Every tenant that cannot be isolated is a contract that cannot be signed. Every kilowatt spent on storage is a kilowatt not spent on compute. V12 was engineered for that operating model: keep every GPU fed, keep every tenant isolated, keep every cluster online, and do it on hardware operators already standardize on.
What is new in V12
V12 extends the HYDRA architecture, VDURA’s High-performance, Yield-optimized, Distributed, Resilient Architecture, with the capabilities multi-tenant GPU infrastructure requires:
Multi-tenant by design. Per-tenant quality of service, namespaces, encryption keys and VLAN isolation on one shared fleet, so a provider can carve a single storage pool into hard-walled tenant services with capacity and performance guarantees.
API-first automation. REST APIs, Kubernetes CSI and infrastructure-as-code tenant provisioning, so storage is deployed, provisioned and billed through the same pipelines as the rest of the GPU cloud.
Context-Aware Tiering™. Data lands on the right media automatically as access patterns shift between training and inference. Roughly 90% of files stay on flash while roughly 90% of capacity settles on HDD, in one platform with no stub files, no rehydration steps and no manual tuning.
Persistent context for inference. A KV cache that outlives the pod. Sessions resume instead of prefilling again, delivering faster first tokens and more concurrent users on the same GPUs, at flash cost rather than recompute cost.
RDMA data paths. Direct GPU-to-storage transfers with the CPU out of the path. The DirectFlow™ parallel client takes roughly 191 MB of DRAM and zero cores from the GPU node.
Elastic Metadata Engine. VeLO™ metadata acceleration of up to 20x improvement, 225,000 creates and deletes per second per Director, and billions of metadata operations per second in aggregate.
File and S3 in one platform. An S3 object is a file in the volume, not a copy of one. No staging copies between ingest, training, inference and archive.
Snapshots and SMR HDD optimization. Instantaneous, space-efficient snapshots for checkpoints and operational recovery, and SMR HDD unlocking 25 to 30% more capacity per rack.
End-to-end encryption. AES-256 at rest and in flight, with KMIP key management per tenant.
Self-healing resiliency and VDURA Sentinel™. Failure domains as small as a single VPOD™, no manual rebuilds and no downtime windows, backed by VDURA SentinelTM proactive support that opens the service request, with the diagnosis attached, before the customer sees a fault.
V12 is qualified on 100% Supermicro Building Block Solutions. The qualified configuration uses the Supermicro AS-1116CS-TN, a 1U system with a single AMD EPYC™ 9005 series processor and 12 NVMe bays, as both the VeLO Director node and the all-flash F-Node, alongside the AS-2015HS-TNR hybrid storage node and the CSE-947HE2C 4U 90-bay JBOD for the mixed-fleet data plane. Every node connects with RDMA straight to the GPU nodes and no dedicated back-end storage fabric.
Built for GPU economics
Clusters grow online from three nodes to thousands, and flash share is a dial rather than a fork. A single platform at roughly 20 PB usable spans a 35x performance range, from a capacity-optimized mixed fleet at 2% flash and 18 kW to an all-flash configuration at 1,000 MB/s per TB, so operators size storage to the workload instead of standing up a second system when the workload changes. The result is 2x+ performance per watt and more than 60% lower total cost of ownership than competitive architectures at the same feed rate, which returns power, rack space and capital to the operator for more GPUs.
Proven at scale
V12 builds on 25 years of parallel file system engineering, from PanFS to VDURA, with more than 1,000 production deployments in over 50 countries and namespaces of more than 1,500 nodes. VDURA Data Platform V12 was named AI Data Management Solution of the Year in the 2026 AI Breakthrough Awards.
Meet VDURA and Thor at Ai Everything Abu Dhabi
VDURA will demonstrate V12 on Supermicro at Ai Everything Abu Dhabi, 6–7 October 2026, ADNEC Centre, Booth H3-D45. VDURA partner Hafþór “Thor” Björnsson (The Mountain from Game of Thrones and Strongman), whose record-setting data lifts have powered VDURA, will be at the booth alongside Team VDURA. Operators building or expanding GPU capacity in the region can book time with the team at AI Everything Abu Dhabi.
Availability
VDURA Data Platform V12 is generally available today for all V5000 class systems and as an upgrade for V11 customers. VDURA SentinelTM is included with V12; proactive service requests and parts dispatch are delivered through VDURACare Premier, VDURA’s 10-year support offering covering hardware, software and 24×7 expert response under a single contract. Learn more at vdura.com/data-platform.
AI agents expose sensitive corporate screenshots from 343 companies
Posted in Commentary with tags Glow on September 30, 2026 by itnerdGlow Security researchers discovered more than 13,000 sensitive screenshots from 343 organizations that AI coding agents had uploaded to publicly accessible GitHub repositories, exposing information including credentials, personal data, internal systems and unreleased products.
The agents were performing legitimate development tasks but encountered a limitation when attempting to attach screenshots from private repositories to pull requests. Instead of stopping or asking for permission, some agents independently worked around the restriction by placing the screenshots in public repositories so developers could view them. Glow said the behavior occurred across multiple AI agents and was not the result of an external attack.
In one case, an agent asked to verify an internal billing screen at a manufacturer with more than 100,000 employees posted screenshots to a developer’s personal GitHub account. The company’s security team was unaware the information had been made public until Glow notified it. Researchers said roughly one-third of the exposures involved GitShot, an open-source screenshot tool whose documentation warns that its image repository is public by default.
Ryan McCurdy, VP of Marketing, Liquibase:
“This is exactly why an AI agent doesn’t have to be compromised or malicious to create a security problem. These agents were trying to complete the task they were given. They hit an obstacle, found another way to accomplish the goal, and exposed sensitive information in the process.
“That’s a very different problem from traditional software. An agent can decide how to accomplish a task, which means enterprises have to think beyond what the agent has permission to access. They also have to decide what actions the agent has the authority to take on its own.
“The answer can’t be asking a person to approve every step. As agents take on more of the SDLC, that won’t scale. The controls need to sit outside the agent and close to the systems where its decisions become actions.
“An agent can make a bad decision. Good governance keeps that decision from becoming a business problem.”
Darin Fredde, Sr. Director of Technical Marketing Engineering, Ridge Security Technology Inc.:
“This is a good example of why AI agent security must extend beyond the model itself. The agents were given a legitimate objective, encountered a constraint, and found a way around it but the workaround crossed a security boundary. There didn’t need to be an attacker for sensitive information to become exposed.
“As organizations give agents more autonomy, we need to test the entire path: the model, tools, permissions, data access, and the environment in which the agent operates. The question isn’t only whether an agent can complete its task, but what it is willing and able to do to complete it. That’s where continuous offensive testing becomes increasingly important.”
There have to be guardrails and other types of security around AI. Otherwise you get a very bad situation. Or put another way, you have to make sure not to be that guy.
Leave a comment »