Agregátor RSS

Switch 2 konečně umí sdílení her řešit systémově. Co je GameShare, jak fungují Virtual Game Cards a kdy má smysl „půjčit“ digitální hru rodině? Prakticky, srozumitelně a bez iluze, že jedna kopie uspokojí celé sídliště.

Vykreslování 3D scén s takzvanými drátovými modely (wireframe) není pro skutečné 3D scény dostačující. Potřebujeme totiž vykreslovat vyplněné stěny těles, nanést na tyto stěny textury a spočítat jejich osvětlení.

Microsoft se nechal překvapit vydáním Apple MacBook Neo. Navzdory tomu, že měl vlastní levné řešení hotové a navzdory tomu, že před Applem mohl mít náskok. A tak nyní šuplík otevírá a oprašuje plány…

Na Northwestern University postavili kvantový cyklotron a chytili jeden jediný pozitron, který vyletěl z rozpadu vzácného radioaktivního izotopu sodíku-22. Dlouhodobým cílem výzkumu přitom není zoologická zahrada antičástic, ale porovnání vlastností elektronu s jeho antihmotovým protějškem pozitronem v rámci pátrání po původu existence hmoty ve vesmíru.

Je jako elektrický blesk. Bateriemi poháněný Apex Recordhunter ambiciózní německé společnosti Quantum Systems dosáhl rychlosti 777 kilometrů za hodinu, což by byl nový rekord pro elektrické drony. Protože ale Quantum Systems nenaplnili přísné požadavky Mezinárodní letecké federace (FAI) pro tento rekord, jde pouze o neoficiální výsledek, který nebyl zařazený do historických tabulek.

Nejprestižnější fyzikální cenou je samozřejmě ta Nobelova. Přestože to paradoxně není cena s nejvyšší finanční prémií pro držitele, tu získá laureát nejvyšší i Průlomové ceny, prestiž Nobelovy ceny lze dosáhnout jen velmi těžko. Nevýhodou Nobelovy ceny pro astronomy je však to, že se o ni dělí se všemi ostatními fyzikálními obory, a tak získají astronomové Nobelovu cenu jen jednou za pár let, a to jen za ty skutečně nejdůležitější objevy.

Planetě Venuši se zde na Oslu věnujeme pravidelně. Již dříve se tak naši čtenáři mohli seznámit s tím, že její atmosféra může být gigantickou laboratoří organické chemie, jak ukázaly experimenty doktora Jana Špačka a jeho týmu. Nyní přišli s dalším dílkem své detektivní skládačky. Ať už je v mracích Venuše cokoli, je to neobyčejně divné, a je toho hodně.

Enterprise-sized businesses spend, on average, 28 percent of their software budgets on unwanted upgrades, migrations, and licensing changes. Often, those firms' IT heads think those changes are detrimental.

Those results are according to a survey of 2,018 chief information officers and senior IT decision-makers at companies with at least 10,000 employees that Origina commissioned for its report, “The Software Tax.” About half of the respondents (1,011) are from the US, and the rest are from the United Kingdom. All respondents worked at companies with at least $1 billion in annual revenue.

Keep in mind that Origina provides maintenance for various enterprise software. Its report points to independent software maintenance as a way for IT leaders to regain control over software budgets, illustrating its potential bias. A third-party research consultancy, Censuswide, conducted the survey.

Read full article

Comments

Hackers compromised the infrastructure of Onamae Desktop Cloud, a popular provider of VPS services in Japan, and installed malware on up to 26,739 customers' servers. [...]

North Korean hackers are using a post-quantum cryptographic mechanism to secure malicious payload delivery in new operations that combine old and new malware. [...]

Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: * Luboš Kocman – Co je nového v openSUSE Leap 16.1 * Lukáš Lánský – Nástroje pro migraci a přechod na novou verzi Nebudou chybět cupcakes, drobné občerstvení a příležitost popovídat si s ostatními příznivci openSUSE. Navíc budete mít možnost nahlédnout do našich nově zrekonstruovaných kanceláří. Kdy: 4. listopadu 2026 od 19:00 (dorazit můžete už v 18:30 na neformální povídání). Kde: SUSE Linux s.r.o., Křižíkova 148/34, Praha 8 – Karlín, 2. patro. Ať už openSUSE používáte, přispíváte do projektu, nebo vás Linux jednoduše zajímá, rádi vás uvidíme. Další informace najdete na stránce openSUSE Launch Parties. Těšíme se na vás v Praze.

GitLab released fixes on October 21 for a flaw that lets an attacker run code on a self-managed server without logging in, and it affects every version of the software going back to 7.0, released in 2014. The fix matters even for administrators who patched nine days earlier: the October 12 update covered only versions 19.2 and later, and the new fixed versions sit one patch above it, so an Swati Khandelwalhttp://www.blogger.com/profile/[email protected]

Every IT and security team knows the feeling of opening a vulnerability report and seeing a number that only goes up. Thousands of findings. Hundreds marked critical. A backlog that grows faster than any team can close it.

For years, the default response has been to work harder: more scans, more tickets, more overtime. But the volume of vulnerabilities, accelerated by AI-assisted discovery and a sprawling mix of endpoints, cloud services, and applications, has outpaced that approach.

Shift from vulnerability counts to exposure reduction →

The question has shifted from, “How do we fix everything?” To, “What should we fix first, and why?”

Vulnerabilities are not the same as exposures

A vulnerability is a weakness in software or configuration. An exposure is a weakness that can realistically be reached and exploited in your environment, with consequences that matter. That difference is where remediation prioritization begins.

A vulnerable library on a decommissioned server with no network access is technically a finding. It is not a meaningful exposure. A misconfigured remote access gateway facing the internet may never appear on a CVE list, yet it can represent serious risk. Focusing on exposure reduction, rather than raw vulnerability counts, helps teams spend limited time where it changes outcomes.

Risk-based prioritization works best when it combines technical and business factors. Is the weakness being actively exploited? Can attackers reach the affected system from the internet or through common lateral paths? What business service does the system support, and what would disruption cost? Does it store or process sensitive data? Are compensating controls already reducing the risk? Consider two findings: a critical-rated flaw on an internal development server with no sensitive data, versus a high-rated flaw on a customer-facing web server with exploit code circulating publicly. On severity alone, the first wins. On actual risk, the second is the clear priority, as Ivanti’s prioritization guide lays out in detail.

From point-in-time scans to continuous compliance

Traditional vulnerability programs often run on a scan-and-report cycle: scan weekly or monthly, generate a report, assign tickets. In a fast-moving environment, those snapshots age quickly. A new exploit for an old flaw should move it up the list immediately, not three weeks later at the next scan.

Continuous compliance closes that gap. Instead of waiting for the next scan, teams monitor for new disclosures, configuration changes, and newly exposed assets as they happen, and reprioritize accordingly. In practice, that might mean an alert when a device that was offline during patching reconnects, or when a new cloud workload appears without an assigned owner — both common sources of hidden exposure that periodic scans tend to miss. Continuous compliance also includes verification and the evidence to prove it. A ticket marked “resolved” is not proof of reduced risk. Confirming that a fix was applied, that the exposure is actually gone, and that the record is audit-ready closes the loop.

Where automated remediation fits

Automation is essential to keep pace, but it works best when matched to the right kind of risk. Routine, well-understood fixes (standard OS and application updates on managed endpoints) are strong candidates for automated remediation with staged rollouts. Configuration corrections that follow established policy can often be automated as well. Start with the fix categories where failures are easiest to detect and roll back.

Higher-impact changes, such as patching production databases or modifying network controls, still benefit from human judgment and scheduled windows. Even then, automation can help by gathering context, preparing changes, and verifying results.

Measure what actually matters

Many teams still report success in patches deployed or tickets closed. Those metrics show activity, not outcomes. More meaningful measures include time to remediate actively exploited vulnerabilities, the number of internet-facing exposures over time, and the share of critical business services with no known exploitable weaknesses. According to Ivanti’s 2026 State of Cybersecurity Report, these are the metrics that tell a clearer story about whether the organization is actually safer. Tracking them monthly also gives IT and security teams a common language for progress.

No organization will ever reach zero vulnerabilities. Chasing that goal burns out teams and distracts from the issues that matter most. The objective is not to fix everything. It is to reduce meaningful risk, continuously and deliberately, with remediation focused where it makes the biggest difference.

Measure what actually matters to reduce real exposure →

For most IT teams, Patch Tuesday used to set the rhythm of the month. Updates arrived, teams tested them, change boards approved them, and deployments rolled out over the following weeks. It wasn’t painless, but it was predictable.

That predictability is gone. Nearly 48,000 CVEs were published in 2025, and the average time to exploit has collapsed to roughly five days. Attackers no longer wait for organizations to finish their testing cycles.

Move from reactive patching to risk-based automation →

Many practitioners now call this the Patch Apocalypse. The name is dramatic, but the operational reality behind it is not. It’s a capacity problem, prioritization problem, and process problem, all at once.

AI is speeding up both sides

Artificial intelligence is changing how vulnerabilities are found. Researchers are using AI-assisted tools to analyze code, fuzz applications, and identify flaws far faster than manual review ever could. In the short run, that means more disclosures, arriving faster, across more software.

The same techniques are available to attackers who can use AI to analyze patches, reverse-engineer fixes, and build working exploits soon after an update ships. The result is a compressed timeline. A vulnerability published on Tuesday may be weaponized before a traditional change window opens the following week.

I’ve watched this shift play out across enterprise environments, and the pattern is consistent: The disclosure-to-exploit window keeps shrinking while patch volumes keep climbing. The old model assumed you had time. You don’t anymore.

Where traditional patching breaks down

Most patch programs were designed around a simple assumption: Deploy updates consistently and risk goes down. That assumption still holds, but the math no longer works.

Consider a typical mid-sized environment with thousands of Windows and macOS endpoints, a mix of Linux servers, dozens of third-party applications, and a growing number of cloud workloads. Each month brings hundreds of relevant updates. Testing each, scheduling every reboot, and confirming every deployment is not realistic with the same headcount.

Teams then fall back on severity scores. But severity alone is a blunt instrument. A critical-rated flaw on an isolated lab server may pose less real danger than a medium-rated flaw on an internet-facing system that attackers are actively targeting. When everything marked critical is treated as urgent, urgency stops meaning anything.

The outcome is familiar to anyone who has managed a patch backlog: healthy compliance percentages on dashboards, and real exposure hiding in the gaps.

Prioritize by risk, not by volume

The more useful question is not, “How many patches did we deploy?” It’s, “Which actions reduce the most risk right now?”

Practical prioritization weighs several factors together: Is the vulnerability being actively exploited in the wild? Is the affected system reachable from the internet or untrusted networks? How important is the asset, and what depends on it? Are compensating controls already in place? Teams that apply these filters often find that a small fraction of open vulnerabilities accounts for most of the meaningful exposure. That fraction is where people, maintenance windows, and testing effort should go first.

Prioritization frees up attention. Automation frees up time. Routine, lower-risk updates (browser patches, common third-party applications, standard OS cumulative updates) can be deployed through automated rings: a pilot group first, then broader waves, with an automatic pause if failure rates spike. That leaves skilled staff to focus on the hard cases: legacy systems that cannot be patched quickly, business-critical servers that need careful scheduling, and emergency fixes for actively exploited flaws.

One practical step I recommend is to run a tabletop exercise before the next urgent disclosure. Pick a realistic scenario and walk through it. How quickly can the team identify every affected device? Who decides whether to patch immediately or apply a workaround? How will you verify the fix actually landed? Keep it short, focused, and blameless. Most teams discover the bottleneck is not the patching tool — it’s incomplete asset data, unclear ownership, or slow handoffs between IT operations and security.

A different definition of success

The Patch Apocalypse is here to stay. Vulnerability volume and exploit speed are structural trends, not temporary spikes. But the goal is not to patch everything; it’s to reduce risk intelligently, focusing effort where it matters most, letting automation handle the rest, and building the visibility and governance underneath so that when the next disclosure hits, your team is ready.

Turn your patch program into a risk-reduction engine with Ivanti →

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) is warning that attackers are actively exploiting four vulnerabilities in Plex Media Server. [...]

For the past few years, most enterprise AI has been advisory. It summarized tickets, drafted knowledge articles, and suggested next steps. A person still decided what to do.

That’s changing. Agentic AI systems can plan multistep tasks and carry them out: querying systems, triggering workflows, changing configurations, and closing tickets with little or no human involvement. Ivanti’s 2026 State of Cybersecurity Report found that 87% of security professionals say integrating agentic AI is a priority, and 77% report at least some comfort letting autonomous systems act without human review.

Secure every AI agent before its first action →

The appeal is obvious for IT teams under constant pressure. So is the risk. An AI that gives a bad answer wastes a few minutes. One that takes a bad action can take down a service.

What “rogue” really looks like

The phrase “rogue AI” conjures images of systems with intentions of their own. In IT operations, the reality is more mundane, and more likely.

An agent told to free up disk space on a server deletes log files an investigation still needs. An agent correcting configuration drift applies a change to every matching device, including kiosks that were intentionally configured differently. An agent running under a broad service account resolves a ticket by resetting access it was never meant to touch. None of these require malice: They happen when an agent has more permission than its task requires, incomplete context, and no checkpoint before high-impact actions.

This is a fundamentally different risk profile than anything we’ve managed before, and most governance models haven’t caught up. We’re applying rules built for chatbots to systems that can change production environments.

From output governance to action governance

Most early AI governance focused on outputs. Is the response accurate? Does it leak sensitive data? Those questions still matter. But when AI can act, governance has to expand to cover behavior. Teams need to define what an agent is allowed to do, under what conditions, against which systems, and with whose approval.

This is a familiar idea in a new setting. IT teams already apply least privilege to human administrators, require change approval for production systems, and keep audit trails for privileged access. Agentic AI needs the same disciplines.

Several controls help keep agents useful without making them dangerous. Give each agent only the access its task requires and avoid shared service accounts. Tier actions by impact: low-risk actions run automatically, while high-risk actions like changes to production servers should require human approval. Set blast-radius limits that cap how many devices an agent can change in a single run, with an automatic pause when failure rates spike. And require reversibility with rollback steps documented and tested.

Accountability and the compliance question

When an agent acts, someone must remain accountable. Every agent should have a human owner, documented purpose, and defined scope. Auditability is just as important. Teams should be able to answer what the agent did, why it did it, what data it relied on, and who approved it. Logs should capture the agent’s inputs and reasoning, not just the final action.

Here’s what elevates this from an operational concern to a board-level one. When an AI agent resorts to deception or unintended vulnerability exploitation to achieve its goals, it’s no longer a technical glitch; it is a potential corporate liability. Compliance needs to move to the front end, engineered into an agent’s lifecycle from the beginning. If an agent makes an unauthorized call, regulators are unlikely to view the model itself as accountable; scrutiny and potential liability will typically fall on the organization deploying it, much as responsibility would for actions taken by a human employee.

Keeping humans in the loop, wisely

Human oversight works best when it’s targeted. If every agent action requires approval, people start clicking “approve” without reading, and oversight becomes theater. A better approach reserves human review for decisions that are high-impact, unusual, or irreversible. Agents can then earn wider autonomy over time, which is a model autonomous endpoint management is built to support.

Agentic capabilities are arriving inside tools IT teams already use, sometimes enabled by default. A practical first step is an inventory: Which tools can take autonomous action, and with what permissions? Pair that with each tool’s approval settings, and you have the beginnings of an action governance policy.

Organizations must govern AI actions, not just outputs. Teams that build those guardrails early will expand automation with confidence rather than hesitation.

Stop governing AI outputs. Start governing AI actions with Ivanti →

Unknown crims compromised LiteLLM's release process on Wednesday, distributing a malicious version (1.107.0) containing malware designed to steal cloud and AI credentials and a remote access trojan (RAT) capable of executing arbitrary code on infected machines through PyPI and Docker registries. PyPI quarantined the trojanized version of the popular open source AI gateway within hours, and the Docker image (litellm/litellm:1.107.0) was removed from both Docker Hub and GHCR soon after - but anyone who ran the compromised package on any platform should assume their secrets have been stolen. “Check for /tmp/.pc_once_* (the exfil has already fired if this file exists) and /tmp/remote_code_loader.lock (the C2 daemon ran or is still running if this file exists),” advised Aikido Security malware hunter Ilyas Makari. “The same applies to anyone who ran the official Docker image litellm/litellm:1.107.0, or pulled it via the latest, main-latest, or main-stable tags.” The most recent safe version is v1.106.2. While it’s too early to tell the scale of this latest LiteLLM supply chain attack – an earlier LiteLLM compromise in March potentially exposed more than 2,500 organizations and 434,000 CI/CD pipelines worldwide, according to CloudSEK – make sure to take these measures seriously, and check environments for any indicators of compromise. Aikido, Google’s Wiz cloud security biz, and supply-chain security provider Socket have all published extensive threat-hunting and mitigation instructions for LiteLLM users and security teams, so give those a read stat. LiteLLM, developed by BerriAI, provides a common interface for LLM providers, including OpenAI, Anthropic, and Google Gemini, and receives about 23 million weekly downloads. This means a compromised installation can run alongside LLM provider API keys, cloud identities, and database connection strings - and expose a ton of valuable credentials, secrets, and other sensitive data to whoever uploaded the malicious package. “Teams using 1.107.0 should stop deploying it and investigate environments where Python ran after installation, including proxy containers and CI runners,” Socket researchers said on Wednesday. The malicious version was uploaded at 11:39 UTC, and according to Wiz kids Benjamin Read and Rami McCarthy, the payload originates with malicious commits made on github.com/Berri-AI/litellm, which is a hyphenated variant of the legitimate BerriAI organization. Miscreants used this repo to inject the three malicious files into the LiteLLM release pipeline. These, according to Makari, include cook.pth, which causes the second file, cook.py, to run automatically every time Python is invoked on the machine, without any additional user action. Meanwhile, cook.py contains the infostealer, and the third file, sitecustomize.py, is the RAT. Python also executes the RAT at interpreter startup, and this file spawns a background daemon that polls the attacker's infrastructure every hour for new commands to execute. Upon executing, the infostealer harvests a ton of sensitive data across 16 modules targeting browsers, cloud providers, and AI services, according to Read and McCarthy. It steals browser credentials and cookies from Chrome, Firefox, Edge, and Safari, along with AWS credentials from ~/.aws/, environment variables, and EC2/ECS instance metadata (IMDS). It also collects users’ Google Cloud Platform service account keys and application default credentials, along with Microsoft Azure tokens from the CLI cache. And then it also swipes API keys for OpenAI, Anthropic, Cohere, and other LLM providers, plus SSH private keys, GPG keys, and shell history files. The malware then encrypts all of this stolen data using AES-256-CBC, wraps the encryption key with an RSA-4096 public key, and sends the encrypted data via HTTP POST to an attacker-controlled domain: http://www[.]litellm[.]dev/healthcheck. BerriAI did not respond to The Register’s inquiries. This is an emerging story, and we will continue to update it as we learn more details.®

“Hallucination” has become the catch-all term for AI getting things wrong. It describes a real phenomenon: Large language models can generate confident, fluent answers that are simply untrue.

But in IT operations, many errors labeled as hallucinations have a more ordinary explanation. The AI isn’t inventing facts. It’s faithfully reporting information that happens to be outdated, incomplete, or contradictory. I’ve seen this play out across enough environments to know the cause usually sits upstream, in the data the system learned from and the picture of the estate it read.

Fix the data foundation under your AI systems →

That distinction matters, because the fixes are different. You don’t tune the model. You fix the information it relies on.

When the answer is wrong, but the logic is right

Imagine a service desk analyst asking an AI assistant whether a user’s laptop has received the latest security update. The assistant says yes. The analyst closes the ticket. Two days later, the device is flagged in a vulnerability scan. What happened? The assistant pulled from an endpoint record last updated before the device went offline for a week. The data was accurate when it was written. It wasn’t accurate when it was used.

Or consider a knowledge article describing a VPN troubleshooting procedure that was retired after a network change. An AI assistant retrieves it, summarizes it neatly, and recommends steps that no longer apply. The model performed well. The source didn’t. In each case, a human reviewer reading the same record would likely have made the same mistake.

This is not a rare edge case. In a 2026 survey of 3,900 employees across six countries, including 1,500 IT professionals, 68% of IT pros reported personally seeing AI produce hallucinations with potential operational impact. Just over half caught the errors before they caused problems, while 16% did not. That’s a significant chunk of wrong answers making it into real workflows, and those are just the ones people noticed.

3 data problems behind unreliable AI

Firstly, most trust issues with AI in IT operations trace back to a few recurring patterns. Poor data quality (missing fields, inconsistent naming, duplicate records) makes it hard for any system to produce accurate answers.

Stale information is the second pattern. IT environments change constantly. Devices move, users change roles, software is updated. Data that was correct last month may be misleading today, especially when AI presents it with no indication of age. Autonomous endpoint management can help keep records current, but many organizations still rely on periodic manual cleanups that leave gaps.

The third is conflicting records. When two systems disagree, AI may pick one arbitrarily, blend them, or produce an answer that matches neither. Without a clear rule for which source wins, the output becomes unpredictable.

Explainability and governance build trust

For IT teams, a useful AI answer isn’t just correct. It’s checkable. When an assistant recommends an action, practitioners need to see where the recommendation came from. Which record did it use? When was it last updated? Did other sources disagree? Explainability turns AI from a black box into a colleague whose reasoning can be reviewed. It also speeds up correction: If an analyst can see that an answer came from a stale knowledge article, they can flag the article instead of losing faith in the entire tool.

The governance measures that reduce unreliable output are less about tuning models and more about maintaining the information they rely on, as the Ivanti Neurons platform is designed to do. Set freshness thresholds so data older than a defined window is flagged or excluded. Establish source-of-truth rules for when systems conflict. Assign owners to knowledge content with scheduled review dates. Log AI recommendations and outcomes so recurring errors can be traced to their source. And give practitioners an easy way to report incorrect answers.

Trust is earned in small moments

Adoption of AI in IT operations rarely fails in one dramatic incident. It erodes gradually, one questionable answer at a time, until practitioners quietly stop using the tool. The reverse is also true. Trust builds when answers are consistently accurate, sources are visible, and errors are easy to trace and fix.

Reliable AI starts with reliable information. The instinct when a system produces a confident wrong answer is to blame the model. Most of the time, the technology did exactly what it was told. It just wasn’t told the truth.

Make your data trustworthy before you trust your AI with it →

Díky smartphonům můžeme dnes fotit kdykoliv a kdekoliv • Při focení však děláme spoustu chyb • Toto jsou ty nejčastější, které dělají snad úplně všichni

The popular LiteLLM Python package has been compromised as part of a software supply chain attack that delivered a credential stealer and a backdoor, according to reports from SafeDep, Socket, StepSecurity, and Upwind. The compromise affects LiteLLM 1.107.0, distributed through PyPI wheels and Docker images. The Python package has since been quarantined on Python Package Index (PyPI), and the Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]