Kategorie

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

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 →

“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 →

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]

Ask an IT team a simple question, “How many laptops do we have?” and the answer often depends on who you ask and which console they open.

For years, that ambiguity was manageable. People reconciled the differences in their heads, in spreadsheets, or in meetings. Ivanti research shows that 34% of organizations still track IT assets in spreadsheets, which shows how much reconciliation still happens by hand.

Build the authoritative data source your AI can act on →

Automation changes the stakes. When software acts on data without a person double-checking it first, the question of which data is correct stops being academic. People tolerate ambiguity and ask questions. Automation doesn’t. It executes at scale and at speed.

What a system of record actually means

A system of record is the authoritative source for a specific type of information. It is the place everyone agrees to trust when systems disagree. That doesn’t necessarily mean a single database holding everything. In most environments, it is more realistic to establish clear authority by data domain. One source might be authoritative for device identity and hardware details, another for user and identity data, another for service relationships and dependencies. What matters is that the authority is explicit, documented, and respected by every process and tool that consumes the data, including automation.

Consider what happens without it. An automated workflow deploys a patch to a device, but the device record is duplicated and the patch targets the wrong machine. A rule flags laptops that haven’t checked in for 60 days as possibly lost, but the check-in dates are stale, so active devices get flagged anyway. If HR and IT systems disagree about an employee’s status, access may be revoked too early or not at all. Each rule is only as good as the data behind it.

Ownership, authority, and traceability

Data ownership and data authority are two concepts that often get blurred. Ownership is about accountability: who is responsible for keeping a data domain accurate, resolving conflicts, and approving changes. Authority is about precedence. When two systems hold different values for the same attribute, which one wins? Both need to be defined. A source can be technically authoritative, but if nobody owns its accuracy, quality will drift.

A practical way to start is to list the 10 to 15 attributes automation relies on most: device name, owner, location, operating system, criticality, last check-in, and assign both an authoritative source and an accountable owner to each.

Traceability matters just as much. When an automated action goes wrong, the first question is always, “Why did it do that?” A trusted system of record makes that question answerable. If teams can trace an action back to the specific record and attribute that triggered it, along with when that data was last updated, troubleshooting takes minutes instead of days. Without it, teams are left reconstructing events from scattered logs and memory.

Context and foundation

Raw records aren’t enough. Automation also needs operational context: which business services a device supports, how critical it is, who depends on it, and what maintenance constraints apply. A server running payroll at month-end should not be treated the same as a test server, even if both share the same vulnerability. Context allows automation to make proportionate decisions instead of uniform ones, and the Ivanti Neurons platform is built to connect asset data with service maps, ownership, and business priorities.

It is tempting to start an automation program with the workflows themselves. They are visible, measurable, and satisfying to build. The data foundation underneath is harder to show off. But teams that skip it tend to automate their inconsistencies and then spend months chasing the side effects. Autonomous endpoint management requires a foundation you can trust, and that investment pays off in every workflow built on top of it.

The organizations getting real value from AI didn’t start with the model. They started with the data. Because without trusted data, AI is just guessing. And in enterprise IT, guessing isn’t a strategy.

Anchor your automation in data you can trust with Ivanti →

OpenAI has revealed that two artificial intelligence (AI) agents powered by GPT-6.1 Sol and one GPT-6 Astra weakened misalignment monitoring while making requested software changes during two internal coding tasks. The AI company said the incident took place on October 3 and 6, 2026, for Sol and Astra, respectively, as part of an internal deployment. "A GPT-6.1 Sol agent repairing an Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]

OpenAI agents powered by the GPT-6.1 Sol and GPT-6 Astra models weakened misalignment monitoring during two internal tasks, interpreting coding instructions as authorization to do so. [...]

Vulnerability overview

On October 20, 2026, the PHP security team published a preliminary notice regarding an upcoming emergency release that addresses two critical vulnerabilities (both rated 9.2 on the CVSS scale). The patches were released on Wednesday, October 21, 2026, at 14:00 UTC.

The release was expedited after information about the vulnerabilities was leaked to the public before the scheduled embargo was lifted. In a post on Hacker News, a user reported two RCE vulnerabilities in PHP, allegedly affecting all versions starting with PHP 5.4.0.

The vulnerabilities in question are CVE-2026-109618 and CVE-2026-109619. Shortly after the post appeared, researchers confirmed the existence of the vulnerabilities. Along with the leak of details, an exploit unofficially named PHP2Shell appeared online. In the leaked demo video, the exploit is shown in action on web servers running WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal, and WHMCS — platforms that power many modern websites. The authenticity of the demonstration and the exact behavior of the exploit had not been independently verified at the time of publication.

According to the researcher who published the PoC, the vulnerabilities are related to the handling of the multipart/form-data MIME type in conjunction with the session upload progress mechanism (session.upload_progress) in the PHP core and fall under the categories of use-after-free and memory corruption. This means that the flaws cannot be patched via application code, and the only possible fix is to update PHP on the server. The attack works without authentication: an attacker with network access to a PHP application can execute arbitrary code on behalf of the PHP process without needing to authenticate. Security advisories issued by PHP on October 21 confirm this information.

The vulnerabilities affect PHP versions 5, 6, 7, and 8. As of this publication, branches from 8.2 to 8.5 are supported. Older branches, including PHP 8.1, 8.0, 7.x, and 5.x, have reached the end of their lifecycle; however, due to the critical severity of the vulnerabilities, backported patches have also been released for versions 7.4, 8.0, and 8.1.

Sansec experts estimate that widespread exploitation could begin within 15 minutes of the update’s release. We strongly recommend that administrators responsible for publicly accessible PHP web servers take the following steps before the patch is available:

1. Conduct an inventory of all PHP-based systems in the infrastructure (including web servers, control panels, third-party software, etc.).
2. Disable upload-progress: set session.upload_progress.enabled = Off using the php_admin_flag in PHP-FPM pools.
3. Block multipart requests on nginx and Apache servers.
4. Consider temporarily isolating PHP applications that connect to the Internet until fixes are released.
5. Ensure readiness to install the patch immediately upon its release.
6. Plan to migrate servers running unsupported versions (8.1 and earlier) to the latest PHP branch.

Detection by Kaspersky solutions

Kaspersky solutions detect the described malicious activity at various stages of the attack. Possible detection scenarios are listed below.

When an attempt is made to exploit these RCE vulnerabilities, Kaspersky Endpoint Detection and Response promptly alerts the user to suspicious actions performed in the context of a web server, on both Linux and Windows machines. This activity is detected by the following rules:

• creating_windows_shell_from_a_web_servers_process;
• possible_web_shell_creating_via_exploit;
• spawning_process_from_webserver_more_filters_linux;
• webserver_interpreter_execution_linux;
• executable_file_in_www_folder.

Detection of the PHP2Shell vulnerability exploit by KEDR

Exploitation of the PHP2Shell vulnerability in network traffic is detected by Kaspersky Anti Targeted Attack (KATA). This solution detects such activity with the following verdicts: Exploit.CVE-2026-109618.HTTP.C&C and Exploit.CVE-2026-109619.HTTP.C&C.

Detection of the PHP2Shell vulnerability exploit by KATA

Our Kaspersky Endpoint Security solution, now available as Kaspersky Next, also detects malicious post-exploitation activity using the Behavior Detection component, such as PDM:Exploit.Linux.Generic and PDM:Exploit.Win32.Generic.

The PHP security team released emergency security patches for two critical remote code execution (RCE) vulnerabilities (CVE-2026-109618 and CVE-2026-109619) tracked collectively as PHP2Shell. [...]

ClickFix attacks are surging as cybercriminals use fake AI installers, malicious search results, and trusted chatbot platforms to trick users into executing malware. Push Security examines how these attacks evade traditional defenses and why AI tools have become increasingly effective lures. [...]

PHP has released emergency updates that fix two critical flaws in the language itself, letting an attacker without an account run code on a web server. The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the PHP team says only updating fully protects a server. The flaws, together called PHP2Shell, sit in the PHP runtime, not in any application, so a site is exposed even when its own Swati Khandelwalhttp://www.blogger.com/profile/[email protected]

Google on Tuesday said it's rolling out improved safeguards in its Chrome browser to secure users against ClickFix attacks when Enhanced Protection is enabled. ClickFix is a popular social engineering technique in which bad actors trick users into copying and pasting malicious code directly into their computer's operating system, thereby bypassing conventional security controls. As part of Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]

Employers are getting pickier when looking at tech resumes, but competition for the right skills is still intense. Companies will pay a premium for experience and advanced AI skills.

“The market is no longer defined simply by how many people employers hire, but by how precisely they hire,” said Ger Doyle, ManpowerGroup’s regional president for North America.

In many cases, employers would rather leave a position open than make the wrong hire, Doyle said.

AI fluency and expertise are driving higher salaries, talent consulting firm Robert Half said after surveying more than 2,000 hiring managers, business leaders, and employed workers for its 2027 salary guide. “72% are increasing pay for relevant AI skills, with 42% offering more for AI-related expertise than other technical skills,” the firm said.

The tech job market today

There were 272,040 new IT openings posted in September, boosting the active listings to 625,633, the highest in more than three years, according to a study released by CompTIA earlier this month. About 349,821 jobs listed in September — more than half the active listings — needed AI skills, growing by 32,327 compared to August, CompTIA said.

In a recent survey of tech and IT service employers, AI literacy was the most in-demand technical skill, with 34% of US respondents naming it as a sought-after skill, reported Experis, part of ManpowerGroup, in its fourth-quarter talent outlook. AI modeling and app development followed close behind at 33%.

“We’re seeing it influence hiring across occupations ranging from data science and engineering to project management and operational roles,” ManpowerGroup’s Doyle said.

Employers face a tug-of-war as workflows transform and job requirements change, said Michael Chui, senior fellow at McKinsey.

“You have to have the right talent in place. You have to retrain. You might have to change the incentives. That’s all hard work,” Chui said.

What skills are sought

AI skills in demand are increasingly tied to business priorities and outcomes, consulting firm PwC said in a June study.

Companies want to hire AI-fluent workers who can hit the ground running. They prefer candidates who have used cutting-edge tools and services.

In tech job postings, employers are seeking more experience but fewer skills, said Dean Boerner, a data scientist at Revelio Labs, in a study published last month. Since late 2024, the average number of skills required in tech job postings dropped from about 30 to 21, while required experience rose from about 4.6 to 4.8 years.

Employers particularly want more years of experience in data-related skills such as data organization, data research, and enterprise architecture design. This translates to hiring experienced personnel rather than handing duties to junior hires or AI systems, Revelio said in its study.

Fewer job listings mention broad categories like software and application development, the study said, while a larger number of job listings mention specialized skills such as Java API development and Python development. Other AI-linked skills including networking, cloud development, and machine learning are also in demand.

The AI infrastructure buildout has also led to an increased demand for semiconductor talent, network architects, construction managers, and software developers.

“Data centers are the factories of the AI economy, and every server rack that comes online needs someone who knows how to run it,” said Kye Mitchell, head of Experis US.

Experts said software developer roles are now pivoting toward data and machine learning expertise. AI is automating coding, so software developers are becoming AI engineers with duties that include verifying AI-derived code and ensuring compliance.

“Governance is a thing in which engineers will have a key role to play… AI engineers build contextual guardrails for compliance,” said Deepak Seth, senior director analyst at Gartner.

Salaries

AI engineer will be among the top-paid jobs in 2027, with salaries ranging from $154,500 to $196,750, depending on experience, according to Robert Half.

AI architects get between $145,250 and $204,000. Salaries for AI/ML analysts, machine-learning engineers, and data scientists range from $121,250 to $186,750.

RPA (robotic process automation) engineers, who focus on software and automation, get salaries between $107,000 and $155,250. Salaries also depend on location.

Career ladder

AI is throwing out the traditional way to climb up the career ladder. Hands-on experience and on-the-job upskilling matter more, while academic credentials carry less weight.

Companies are looking for specialized, judgment-heavy skills, “which younger workers are the least equipped to offer,” Revelio Labs said in its study. 

PwC noted that entry-level roles in AI-exposed jobs now demand skills that are traditionally developed through experience, such as leadership and strategic thinking.

“Organizations must rethink how they mentor and train junior staff, helping them step up to complex decision-making much earlier in their careers,” PwC said in its June report.

Fresh graduates combining technical fundamentals with practical experience, AI fluency, and strong communication skills will stand out, Experis’ Mitchell said.

“[Employers] are also building talent from within, expanding talent pools, and using multiple strategies to meet their needs,” Mitchell said.

Proof of AI proficiency in the workplace will become a standard requirement, Gartner’s Seth said. By 2027, 75% of hiring processes will include certifications and testing for workplace AI proficiency during recruiting, he said.

“Anybody in the IT world knows… we were asked for certifications about Java or C++ or whatever. Now suddenly that will shift to workplace AI proficiency,” Seth said.

Skills are also going out of date faster. “The half-life of technical skills will shorten from 8 to 12 years to 2 to 5 years. So adaptability and learning velocity will become very, very key,” Seth said.

“Rehiring is expensive. Reskilling is a better option,” Seth said.

Microsoft has released PowerToys 0.102, with two new mouse utilities, new command-line tools, and Command Palette improvements. [...]

The embargo for iPhone Duo reviews has broken, which means dozens of reviews have appeared all at once. It’s like sitting in an empty office with all the phones ringing at the same time. No one can answer all of them.

So, what are reviewers saying about Apple’s new $2,000 product? What’s hot? What’s not? And what’s next?

Let’s begin with the criticisms. 

Almost every review I read is critical about the same things: the lack of a telephoto lens on the camera, the decision to use Touch ID, and lagging third-party software support for the device, with some criticism of the FaceTime camera. 

To be fair, one of those criticisms will change as developers build iPhone Duo support for their applications, while others will change in future versions of the device.

A convincing case for foldables

Reviewers seem to agree that Apple has plucked all the best ideas introduced in foldables so far and wrapped them in a highly designed, well-executed, luxurious product they think sets the scene for the next generation of foldable smartphones. As the history of most Apple product introductions shows, first-generation compromises will be overcome.

The iPhone Duo form factor itself, however, seems to be a success.

“For an iPhone user who has never experienced a foldable, I suspect they will be surprised by how quickly the larger display starts to feel useful,” wrote Francisco Jeronimo, IDC vice president, worldwide devices, in a note seen by Computerworld. “Apple has made a convincing case for this form factor. Now comes the next test: turning excitement into availability, adoption and a lasting new chapter for the smartphone market.”

Here’s what the first reviewers have to say “Masterfully-designed”

“The iPhone Duo is a masterfully designed product that earns its two grand price tag. By borrowing the same aspect ratio as a notepad, it feels compact when folded and expansive when opened up to double in size. It’s crazy thin — just 5.2mm when folded flat — and littered with small design choices that add up to an overwhelming sense of luxury,” wrote Robert Leedham at GQ.

“Hype is justified”

“After a week of testing, I can say that hype is justified. Its polished design and thoughtful craftsmanship, headlined by a unique inner display and hinge design, set a new platinum standard for folding phones, and serve as a shot in the arm of the entire smartphone ecosystem. Needless to say, the Duo is the best foldable phone I’ve tested to date, and the freshest, flashiest phone I’ve used in years,” wrote Stefan Vazharov at Popular Mechanics. 

You may not need it

“If you want the convenience of a larger screen without carrying two devices, the Duo could be a compelling proposition. But if you prefer to use your phone and tablet separately, you’re paying a premium for a folding design you may not need,” wrote Shivali Best at the Daily Mail.

“An incredible piece of engineering”

“It’s hard to overstate just how impressive the whole thing feels in practice. The hinge feels fantastic, the smaller footprint makes it surprisingly easy to carry, and you can unfold it into a 7.6-inch display. It’s an incredible piece of engineering, and even after a week, I’m still impressed by how well the entire package comes together,” wrote Chance Miller at 9to5Mac.

“Satisfying“

“’Satisfying’ is the best way to describe the feeling of repeatedly opening and closing the iPhone Duo. It’s as if Apple inadvertently created a digital fidget spinner — the more I carried around the iPhone Duo, the more I found myself absentmindedly folding and unfolding the phone,” wrote Lance Ulanoff at TechRadar.

Cohesive. Intuitive. Useful

“Thoughtful software integrations … give the Duo’s unique design a practical purpose beyond the novelty. The result is a foldable experience that feels cohesive, intuitive and genuinely useful, which could help win over more people to foldables in general. But I think that broader appeal is still a ways off,” wrote CNET’s Abrar Al-Heeti.

“A little bit like magic”

“If you care about having the fanciest phone, this is the one. It’s a neat little book-like iPhone when folded. But that inner display, once you open it, is the nicest phone display I’ve ever seen. It’s matte and has a 120Hz refresh rate, so when you lay the unfolded Duo on a table, a still image on the display appears solid, like a painting… The transition effect Apple’s designers have conjured for opening and closing the phone does look a little bit like magic,” wrote Mashable’s Stan Schroeder.

“Strong and smooth”

“Early folding phones had creaky hinges that felt grindy and didn’t always open fully. Those pioneering devices led the way, to be sure, and they deserve credit for being first to market with those designs. But none of the four competing folding devices on my desk (all from 2026) have a hinge that feels this strong and smooth,” wrote PC Mag‘s Eric Zeman.

“Worth the wait”

“While the Duo is heavy, expensive and late to the market compared to its Android rivals, it encompasses some of the best tech used by its competitors while also redeeming features that other manufacturers have seemingly left for dead. And even though many apps still need to be optimized to fully take advantage of the Duo’s design, the release of Apple’s first foldable has been worth the wait,” said Engadget’s Sam Rutherford.

“Something magical”

“At the risk of sounding cliche, there’s something magical about using the iPhone Duo. The way it seamlessly transitions from phone to tablet and back again. The fact that you can’t even feel the crease — though it is visible. And the way the software reacts based on the angle of the device,” writes Mark Spoonauer at Tom’s Guide.

My take

Having read these reviews, I don’t think any of them will quell enthusiasm for Apple’s $2,000 device. I also think its introduction will help Apple create a mind shift among consumers, some of whom may recall when the $499 entry-level price Apple charged for the original iPhone was seen as too expensive. 

In this case, by combining premium hardware design with smart software decisions, Apple seems to have created an experience many consumers will value. Even those who don’t will probably spend time snapping the fold on the display units at their local Apple Store, if only to find out if doing so really is “satisfying” enough to spend two thousand bucks on a machine for doom scrolling and taking pictures of the family cat.

I believe Apple has reset the industry and will sell as many of these things as it is able to create. I also look forward to seeing what it comes up with next year. There’s only eleven months — and the many stages of new Apple product rumor — until we find out. That suggests the first well-timed Bloomberg rumor will slip just before Christmastime…

Now please subscribe to my daily, human-curated Apple-related news headline feed at The Core, or follow me on BlueSky, LinkedIn, or Mastodon.

Cybersecurity researchers have disclosed details of a previously undocumented China-aligned threat cluster known as Bronze Sandcastle that has been observed targeting organizations in Asia and Africa since mid-2025. "The most distinctive technical marker for Bronze Sandcastle is its consistent use of Sandboxie DLL sideloading," Sophos security researcher Gabor Szappanos said in a post publishedRavie Lakshmananhttp://www.blogger.com/profile/[email protected]