seclists.org
From: Simon Josefsson <simon () josefsson org>
Date: Tue, 20 Jan 2026 15:00:07 +0100
If you are tired of modern age vulnerabilities, and remember the good
old times on bugtraq, I hope you will appreciate this one. If someone
can allocated a CVE, we will add it in future release notes.
/Simon
The telnetd server invokes /usr/bin/login (normally running as root)
passing the value of the USER environment variable received from the
client as the last parameter.
If the client supply a carefully crafted USER environment value being
the string "-f root", and passes the telnet(1) -a or --login parameter
to send this USER environment to the server, the client will be
automatically logged in as root bypassing normal authentication
processes.
This happens because the telnetd server do not sanitize the USER
environment variable before passing it on to login(1), and login(1)
uses the -f parameter to by-pass normal authentication.
Severity: High
Vulnerable versions: GNU InetUtils since version 1.9.3 up to and
including version 2.7.
On a Trisquel GNU/Linux 11 aramo laptop:
root@kaka:~ sudo apt-get install inetutils-telnetd telnet
root@kaka:~ sudo sed -i 's/#<off># telnet/telnet/' /etc/inetd.conf
root@kaka:~ sudo /etc/init.d/inetutils-inetd start
root@kaka:~ USER='-f root' telnet -a localhost
...
root@kaka:~#
The bug was introduced in the following commit made on 2015 March 19:
https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c288b87139a0da8249d0a408c4dfb87
Based on mailing list discussions:
https://lists.gnu.org/archive/html/bug-inetutils/2014-12/msg00012.html
https://lists.gnu.org/archive/html/bug-inetutils/2015-03/msg00001.html
It was included in the v1.9.3 release made on 2015 May 12.
Do not run a telnetd server at all. Restrict network access to the
telnet port to trusted clients.
Apply the patch or upgrade to a newer release which incorporate the
patch.
Disable telnetd server or make the InetUtils telnetd use a custom
login(1) tool that does not permit use of the '-f' parameter.
The template for invoking login(1) is in telnetd/telnetd.c:
/* Template command line for invoking login program. */
char *login_invocation =
#ifdef SOLARIS10
/* TODO: `-s telnet' or `-s ktelnet'.
* `-u' takes the Kerberos principal name
* of the authenticating, remote user.
*/
PATH_LOGIN " -p -h %h %?T{-t %T} -d %L %?u{-u %u}{%U}"
#elif defined SOLARIS
/* At least for SunOS 5.8. */
PATH_LOGIN " -h %h %?T{%T} %?u{-- %u}{%U}"
#else /* !SOLARIS */
PATH_LOGIN " -p -h %h %?u{-f %u}{%U}"
#endif
;The variable expansion happens in telnetd/utility.c:
/* Expand a variable referenced by its short one-symbol name.
Input: exp->cp points to the variable name.
FIXME: not implemented */
char *
_var_short_name (struct line_expander *exp)
{
char *q;
char timebuf[64];
time_t t;
switch (*exp->cp++)
{
case 'a':
#ifdef AUTHENTICATION
if (auth_level >= 0 && autologin == AUTH_VALID)
return xstrdup ("ok");
#endif
return NULL;
case 'd':
time (&t);
strftime (timebuf, sizeof (timebuf),
"%l:%M%p on %A, %d %B %Y", localtime (&t));
return xstrdup (timebuf);
case 'h':
return xstrdup (remote_hostname);
case 'l':
return xstrdup (local_hostname);
case 'L':
return xstrdup (line);
case 't':
q = strchr (line + 1, '/');
if (q)
q++;
else
q = line;
return xstrdup (q);
case 'T':
return terminaltype ? xstrdup (terminaltype) : NULL;
case 'u':
return user_name ? xstrdup (user_name) : NULL;
case 'U':
return getenv ("USER") ? xstrdup (getenv ("USER")) : xstrdup ("");
default:
exp->state = EXP_STATE_ERROR;
return NULL;
}
}Thus there is potential for similar vulnerabilities for other
variables.
On non-GNU/Linux systems, only the remote hostname field is of
interest. The remote_hostname variable is populated in the function
telnetd_setup from telnetd/telnetd.c by calling getnameinfo() or
gethostbyaddr() depending on platform. This API is generally not
considered to return trusted data, thus relying on it to not return a
value such as 'foo -f root' is not advisable.
We chose to sanitize all variables for expansion. The following two
patches are what we suggest:
https://codeberg.org/inetutils/inetutils/commit/fd702c02497b2f398e739e3119bed0b23dd7aa7b
https://codeberg.org/inetutils/inetutils/commit/ccba9f748aa8d50a38d7748e2e60362edd6a32cc
This vulnerability was found and reported by Kyu Neushwaistein aka
Carlos Cortes Alvarez on 2026-01-19.
Initial patch by Paul Eggert on 2026-01-20. Simon Josefsson improved
the patch to also cover similar concerns with other expansions.
This advisory was drafted by Simon Josefsson on 2026-01-20.
bleepingcomputer.com
By Sergiu Gatlan
January 21, 2026 12:49 PM
Fortinet customers are seeing attackers exploiting a patch bypass for a previously fixed critical FortiGate authentication vulnerability (CVE-2025-59718) to hack patched firewalls.
Fortinet customers are seeing attackers exploiting a patch bypass for a previously fixed critical FortiGate authentication vulnerability (CVE-2025-59718) to hack patched firewalls.
One of the affected admins said that Fortinet has allegedly confirmed that the latest FortiOS version (7.4.10) didn't fully address this authentication bypass vulnerability, which should've been patched in early December with the release of FortiOS 7.4.9.
Fortinet is also reportedly planning to release FortiOS 7.4.11, 7.6.6, and 8.0.0 over the coming days to fully patch the security flaw.
"We just had a malicious SSO login on one of our FortiGate's running on 7.4.9 (FGT60F). We have a SIEM that caught the local admin account being created. Now, I have done a little research, and it appears this is exactly how it looked when someone came in on CVE-2025-59718. But we have been on 7.4.9 since December 30th," the admin said.
The customer shared logs showing that the admin user was created from an SSO login of cloud-init@mail.io from IP address 104.28.244.114. These logs looked similar to previous exploitation of CVE-2025-59718 seen by cybersecurity company Arctic Wolf in December 2025, which reported that attackers were actively exploiting the vulnerability via maliciously crafted SAML messages to compromise admin accounts.
"We observed the same activity. Also running 7.4.9. Same user login and IP address. Created a new system admin user named "helpdesk". We have an open ticket with support. Update: The Fortinet developer team has confirmed the vulnerability persists or is not fixed in v7.4.10," another one added.
BleepingComputer reached out to Fortinet multiple times this week with questions about these reports, but the company has yet to reply.
Until Fortinet provides a fully patched FortiOS release, admins are advised to temporarily disable the vulnerable FortiCloud login feature (if enabled) to secure their systems against attacks.
To disable FortiCloud login, you have to navigate to System -> Settings and switch "Allow administrative login using FortiCloud SSO" to Off. However, you can also run the following commands from the command-line interface:
config system global
set admin-forticloud-sso-login disable
end
Luckily, as Fortinet explains in its original advisory, the FortiCloud single sign-on (SSO) feature targeted in the attacks is not enabled by default when the device is not FortiCare-registered, which should reduce the total number of vulnerable devices.
However, Shadowserver still found over 25,000 Fortinet devices exposed online with FortiCloud SSO enabled in mid-December. At the moment, more than half have been secured, with Shadowserver now tracking just over 11,000 that are still reachable over the Internet.
CISA has also added the CVE-2025-59718 FortiCloud SSO auth bypass flaw to its list of actively exploited vulnerabilities, ordering federal agencies to patch within a week.
Hackers are now also actively exploiting a critical Fortinet FortiSIEM vulnerability with publicly available proof-of-concept exploit code that can enable them to gain code execution with root privileges on unpatched devices.
cybernews.com/
Vilius Petkauskas
Deputy Editor
Luxshare, one of Apple’s key partners in assembling iPhones, AirPods, Apple Watches, and Vision Pro, allegedly suffered a data breach, orchestrated by a ransomware cartel. The attackers are threatening to leak data from Apple, Nvidia, and LG unless the company pays a ransom.
Key takeaways:
Luxshare, Apple's key iPhone assembler, allegedly suffered a ransomware attack threatening confidential product data leaks from multiple tech giants.
RansomHub attackers claim access to 3D CAD models, circuit board designs, and engineering documentation from Apple and Nvidia products.
Cybernews researchers claim leaked data includes confidential Apple-Luxshare repair projects, employee PII, and product design files from 2019-2025.
The breach could enable competitors to reverse-engineer products, manufacture counterfeits, and exploit hardware vulnerabilities in Apple devices.
Key Takeaways by nexos.ai, reviewed by Cybernews staff.
The Luxshare data breach allegedly occurred last month, with attackers claiming December 15th, 2025, as the date Apple key partners’ data was encrypted. The alleged attackers, RansomHub, announced the Luxshare data breach on their dark web forum.
Luxshare is an essential partner to the American giant. Many Apple products, including iPhone, AirPods, Apple Watch are assembled at Luxshare, which means the company has very intimate information about Apple’s products.
The conversation on this topic is live. Join in the discussion.
“We were waiting for you for quite some time, but it seems that your IT department decided to conceal the incident that took place in your company. We strongly recommend that you contact us to prevent your confidential data and project documents from being leaked,” the attackers claim.
We have reached out to the company and will update the article once we receive a reply. We have also reached out to Apple and will add its response as soon as we receive it.
Luxshare data breach claims on the dark web
Attakers' post announcing Luxshare data breach. Image by Cybernews.
What data did the Luxshare data breach expose?
The Cybernews research team investigated the data sample that the attackers attached to the post.
According to our team, the leaked data includes details on what appear to be confidential projects regarding device repair and shipping between Apple and Luxshare, including timelines, detailed processes, and information about other Luxshare clients.
Moreover, the leaked information appears to include personal identifiable information (PII) of individuals working on specific projects, with their full names, job positions and work emails exposed.
Luxshare data breach projects
Alleged information on Apple and Luxshare projects. Image by Cybernews.
“Dates of these projects range from 2019 to 2025 and the information appears to expose sensitive business operations. Additionally, .dwg and gerber files, which are often used to create product model designs, are also included,” the team explained.
While Apple’s assembler data breach is still unconfirmed, the team believes that the information included in the post appears to be legitimate.
Luxshare data breach team info
Alleged information about Luxshare staff working on Apple projects. Image by Cybernews.
What do the Luxshare attackers say?
The RansomHub attackers claim to have wide access to confidential Luxshare client data. The stolen data supposedly ranges from 3D product models to circuit board design data, information that’s highly coveted by corporate spies.
According to the attackers, they have accessed archives that contain:
Confidential 3D CAD product models, 3D engineering design data, 3D engineering documentation
Access to high-precision geometric data for Parasolid products
2D component drawings for manufacturing
Mechanical component drawings
Confidential engineering drawings in PDF format
Electronic design documentation
Electrical and layout architecture data
Printed circuit board manufacturing data
“The archives contain data from Apple, Nvidia, as well as LG, Geely, Tesla, and other large companies whose production and R&D information is publicly available. Protected by a non-disclosure agreement,” the attackers claim.
If confirmed, the attack could be disastrous for Luxshare and its partners. For one, attackers could sell the data to competitors who could utilize the stolen details to reverse-engineer products, bypass years of R&D, and manufacture counterfeits.
The cybersecurity implications are also extreme as attackers could clearly uncover hardware vulnerabilities, chip locations, and power systems, which would be beneficial to target firmware or carry out supply chain attacks.
China-based Luxshare is a behemoth in the electronics manufacturing industry. Based in the country’s tech heart, Shenzhen, the company employs over 230,000 people and reports revenues of over $37 billion.
According to reporting by the Wall Street Journal, Luxshare’s importance to Apple’s supply chain ballooned after its main assembler, Foxconn, went through a series of production halting protests.
Who are the Luxshare attackers?
First spotted in 2024, RansomHub is a well established actor in the ransomware scene. For example, the gang proved itself to be one of the most active ransomware gangs of the past couple of years.
According to security experts, RansomHub is among the most prolific ransomware-as-a-service (RaaS) operations, emerging after ALPHV (BlackCat) disappeared. It primarily targets industrial manufacturing and healthcare.
RansomHub brought some technological innovations to the table. Its tools are capable of remote encryption. The affiliates exploit exposed unprotected machines, reducing the risk of detection and increasing the success rate of attacks.
According to a CISA advisory, the cybercrooks breached nearly 500 victims in 2024, almost at a rate of one victim per day. The cyber watchdog also provides a full list of the Kremlin-backed gang's known IOCs, including IP addresses, tools, known URLs, email addresses, and more.
Updated on January 19th [01:30 p.m. GMT] with a insights from the Cybernews research team.
ynetnews.com
Lior Ben Ari, News Agencies|01.19.26 | 02:22
Messages against the regime, documentary footage of protests, and speeches by Crown Prince Reza Pahlavi are seen on the screens of Iranian channels received via satellite; 'Message to the Iranian army and security forces: Do not turn your weapons on the people'
ran’s opposition television channel Iran International reported Sunday evening that satellite broadcasts of several Iranian state TV channels were hijacked, with anti–ayatollah regime protest messages and statements by Crown Prince Reza Pahlavi aired for several minutes. Pahlavi, the exiled son of the shah ousted in the 1979 Islamic Revolution, has in recent weeks sought to position himself as a leader of the protests aimed at toppling the regime.
According to Iran International, the messages were seen by viewers watching Iranian state channels via the Badr satellite. During the brief takeover, videos and images documenting protests against the regime appeared on screen, alongside a call by Prince Reza Pahlavi urging the Iranian people to join the demonstrations and appealing to the armed forces to side with the protesters. The opposition outlet noted that Iran’s state broadcasting authority relies on the Badr satellite to transmit a number of regional channels nationwide.
Videos circulating on social media showed on-screen messages such as: “People of Iran, continue your struggle. Freedom is closer than ever,” as well as “Europe is with you!” and “Prince Reza Pahlavi is our voice, he is mobilizing global support for us.” For several seconds, another message flashed repeatedly: “This is a message to the Iranian army and security forces: Do not turn your weapons on the people. Join the nation for Iran’s freedom!” A photograph of Iranian President Masoud Pezeshkian later appeared, alongside a written appeal addressed to him: “Mr. Pezeshkian, the moment of truth has arrived. Do you stand with those spreading lies about ‘mercenaries,’ ‘Mossad agents’ and similar nonsense?”
The satellite broadcast hack came as the Islamic Republic remains largely cut off from the outside world, a week and a half after authorities shut down internet access. NetBlocks, an organization that monitors internet traffic and cybersecurity, reported that Iran briefly saw an uptick in connectivity earlier Sunday after usage had hovered at about 1% of normal levels over the past week, before dropping again later in the day. According to NetBlocks, there was a sudden spike in access to Google and certain messaging services from inside Iran, allowing a small number of Iranians to relay detailed information about the severity of conditions on the ground. That window was short-lived, however, as internet traffic soon plunged again.
Iran’s authorities cut internet access on January 8, the day protests against the regime escalated into mass demonstrations and, according to reports, the deadliest day of clashes with security forces. Earlier Sunday, Pezeshkian said that, given the need to ease online business activity and reduce communications restrictions, he had recommended that the secretary of the Supreme National Security Council remove internet limitations as soon as possible, though he did not specify when this would happen.
Journalists with Agence France-Presse in Tehran reported Sunday that they were briefly able to connect to the global internet in the morning, even as major internet service providers remained blocked. Some Iranians were able to send and receive WhatsApp messages for the first time in days. International phone calls to and from Iran, which were blocked last week, were restored on Tuesday, and SMS services resumed on Saturday.
Despite the severe restrictions on internet access and Iran’s longstanding bans on certain apps—including Instagram and Facebook, which require VPNs to access—reports of atrocities committed by security forces against protesters have nonetheless leaked out in recent days, mainly via users connected to Elon Musk’s Starlink satellite internet service.
Earlier Sunday, Iran’s semi-official Fars news agency reported that the CEO of Irancell, the country’s second-largest mobile operator, had been dismissed after failing to comply with a government order to shut down the internet. Iranian state television reported that schools and universities reopened Sunday after being closed for a week, saying authorities had regained control of the situation.
Iran admits 5,000 killed, toll may be far higher
Earlier in the evening, Pezeshkian warned that any attack on Iran’s supreme leader, Ali Khamenei, would be considered a declaration of all-out war against the Iranian nation, and that the Islamic Republic’s response to any military aggression would be severe and regrettable. His remarks followed comments a day earlier by former U.S. ambassador to Israel Dan Shapiro, who said he believed President Donald Trump would attempt to kill Khamenei as early as this week.
In a post on the X platform on Sunday evening, Pezeshkian wrote: “If there are difficulties and hardships in the lives of the dear people of Iran, one of the main causes is the long-standing hostility and inhumane sanctions imposed by the U.S. government and its allies. Any harm to the supreme leadership of our country would amount to a declaration of all-out war against the Iranian nation.”
Trump has signaled in recent days that he has decided, for now, to pause any strike on Iran—falling short of the promise he made to the Iranian people at the height of the unrest a week and a half ago that “help is on the way,” urging them to continue fighting the regime. Still, over the past 24 hours, threats and insults have again been exchanged between Trump and Iran’s leadership. In the background, the United States continues to move an aircraft carrier and forces suited for a large-scale strike closer to the Middle East, leading many to believe the likelihood of a U.S. attack remains high.
In a series of posts on X, Khamenei on Saturday harshly attacked Trump, claiming the United States was responsible for the wave of protests sparked by Iran’s dire economic situation. “Responsibility must be placed on the United States,” he wrote, adding: “We find the U.S. president guilty of all the losses, damages and slander.” Trump responded in an interview with Politico, calling Khamenei a sick man and saying, “It’s time to look for new leadership in Iran.”
On Sunday morning, an Iranian official told Reuters that at least 5,000 people have been killed in the crackdown on protests since the beginning of the month. He said the dead included about 500 members of the security forces and, in line with the regime’s official narrative, blamed the deaths of “innocent civilians” on “terrorists and armed rioters,” whom he claimed were armed by Israel and other foreign actors. A day earlier, Khamenei himself acknowledged that “thousands” had been killed in the suppression of the protests, also pointing the finger at the United States, Trump and “the Zionists,” as he put it.
According to the Iranian official who spoke to Reuters, the final death toll is not expected to rise significantly. However, unverified reports suggest the number of fatalities is far higher. Britain’s Sunday Times reported Sunday morning that, according to doctors in Iran, the death toll may exceed 16,000. Citing a medical report compiled inside Iran and leaked by doctors using Starlink, the paper said between 16,500 and 18,000 protesters had been killed and about 330,000 wounded, including children and pregnant women.
On Saturday night, the U.S.-based Human Rights Activists News Agency (HRANA), which reports on Iran through a network of activists, said it had verified 3,308 protest-related deaths, but was still investigating another 4,382 cases, meaning the toll could rise sharply. HRANA said more than 24,000 protesters had been arrested, and despite Trump’s claim that Iran halted 800 planned executions of detainees, it is highly possible that many will eventually be tried and executed, as Iran has done after previous protest waves, including the 2022 “hijab protests.”