Smashing Security 490 Examines Kushner Phone Hacking Claims and Weak Security Keys

Phones, keys and the information people leave online

Episode 490 of the “Smashing Security” podcast brings together several kinds of security failure that are easy to treat as separate problems. Cybersecurity expert Graham Cluley and guest James Ball discuss claims in a new book that Jared Kushner’s iPhone was hacked twice, consider the limits of phone security, and examine how trusted internet security keys were protected by tiny PINs, including one reportedly set to “4.” The episode also turns to a PHP incident called “PHPocalypse” and the risks created by information about company executives and public officials being available online.

There’s a common thread: security depends on more than the device or software in front of you. Phones, authentication keys, software projects and personal information each sit inside a wider system of users, operators and decisions. A failure at one point can change the risk elsewhere.

What a phone can and can’t protect

A smartphone is often the most sensitive computer a person carries. It can hold private messages, account access, contacts and work material, while also serving as a way to approve logins or reset passwords. That concentration makes a phone an attractive target. If an attacker can gain access to the device or an account tied to it, the consequences may extend beyond a single piece of hardware.

The claims about Kushner’s iPhone are allegations discussed on the podcast, and they shouldn’t be treated as independently established details on the basis of the source alone. Still, the subject raises a useful question: what does it mean to say a phone was hacked? The phrase can describe different things, from unauthorized access to an account to compromise of the device itself. Those routes involve different weaknesses and call for different protections.

That distinction matters because a phone’s security is not a single setting. Device updates, account recovery methods, passwords, authentication choices and user behavior all play a part. A device may be carefully protected and still be exposed through an account elsewhere; a well-secured account can still be put at risk if access to the phone is compromised. No single safeguard can carry the whole burden.

This is more significant than it looks. Public discussion often reduces phone security to a question of whether a particular model is “secure,” as if the answer were permanent and universal. In practice, security is a chain of choices and protections, and the weakest link can sit outside the phone itself.

Why a trusted security key can still be vulnerable

Security keys are designed to strengthen account sign-in by requiring a physical item in addition to, or in place of, a password. Their value comes from making remote account theft harder: an attacker who knows a password may still need access to the key. But the episode’s discussion of tiny PINs shows why the word “trusted” shouldn’t end the analysis.

A PIN can protect a key or control access to a feature, depending on how the system is designed. If that PIN is easy to guess, it may weaken the protection the key is meant to provide. A PIN set to “4,” as described in the source, is an especially plain example of a predictable choice. The details of the particular keys and the incident aren’t provided here, so it would be wrong to assume exactly how an attacker could have exploited them. The broader lesson is clear: a strong security device can be undermined by a weak credential or poor configuration.

And this is the part most people overlook: security products are used by people, and people make setup decisions. A tool can offer strong protections while still depending on choices that are easy to get wrong. Organizations can buy security hardware, but they also need sensible setup procedures and clear guidance about PINs and account recovery.

For users, the practical question isn’t simply whether a key is considered secure. It’s how the key is configured, what it protects, and what happens if it’s lost or misused. The episode’s example is a reminder that a product’s reputation doesn’t automatically make every use of it safe.

PHPocalypse and the risks of shared software

The episode also covers a PHP incident dubbed “PHPocalypse.” The source doesn’t specify what happened, which systems were affected or what the consequences were. That limits what can responsibly be said about this particular incident. Its inclusion does, however, point to a broader concern: software used across many projects can become a security concern when a flaw, exposure or maintenance problem reaches the shared layer on which other services depend.

PHP is a programming language used to build web applications. As with other widely used software, the security of a system built with it depends on more than the language itself. Developers choose libraries and components, configure servers, maintain code and respond to reported problems. A weakness in one dependency can matter to projects that rely on it, while a poorly maintained application can remain exposed even when safer options are available.

That’s why software incidents can be difficult to assess from a label alone. A memorable name can help people recognize a story, but it doesn’t explain the technical cause or indicate how widespread the effects were. The useful questions are more specific: what component failed, who relied on it, what access was at risk, and what steps were taken to address the issue? The supplied description doesn’t answer those questions, so the episode’s treatment should be understood as a discussion of an incident rather than a complete technical account.

Public information as a security problem

With Chuck Randolph of 360 Privacy, the episode examines how easily online information can put company executives and public officials in danger. That’s a different security problem from breaking into a device, but it can feed into one. Details about a person’s work, routines or connections may help someone target them, impersonate them or make a convincing approach. The source doesn’t identify particular data or incidents, so the point is about the general risk of personal information being accessible and combined.

Information that seems harmless on its own can become more revealing when gathered from several places. A public profile, a company page and other online records may each expose a small piece of a person’s life. Put together, those fragments can help an outsider build a picture of who the person is and how to reach them. The risk is not limited to famous people: executives and public officials may have responsibilities or access that make their accounts especially attractive targets.

If you're working in this space, it helps to treat personal exposure as part of an organization’s security planning. That doesn’t mean every public detail is dangerous, or that people can remove themselves from the internet. It means asking which information is necessary to publish, what can be limited, and whether staff know how to handle suspicious requests that appear informed and credible.

Here’s the thing: technical defenses can’t fully compensate for information that makes a target easier to identify or approach. Security teams may focus on devices and accounts because those controls are visible and measurable. The human context is less tidy, but it can shape whether an attack succeeds.

What the episode’s examples add up to

Taken together, the topics in Episode 490 show why security problems rarely stay neatly within one category. A phone may expose accounts; a weak PIN may reduce the value of a security key; a software issue may affect systems that depend on shared components; and public information may help an attacker choose a target or craft a credible message. Each problem has its own technical details, but each also depends on how people and organizations manage access.

That said, the source offers only a short account of the episode. It doesn’t establish the details behind the claims about Kushner’s phone, explain the mechanics of “PHPocalypse,” or identify what specific public information creates danger. Readers should keep those limits in view. The value here is in the questions the cases raise, not in treating a brief description as a full incident report.

The broader takeaway is plain: security tools matter, but so do configuration, maintenance and judgment about what information is exposed. A key with a weak PIN, a phone tied to sensitive accounts or a public profile that reveals too much can each create a different opening. Not every exposure leads to an attack. But each can make the next step easier.