📰 English IT Daily · 2026-06-18

A security researcher says he discovered a serious weakness in systems linked to the FIFA World Cup after signing up for FIFA’s public football agent portal. According to his blog post, the registration process added his new account to the same identity system used for many internal FIFA platforms. He only needed his personal ID and email verification to create the account. At first, one FIFA app showed an access-denied message, which suggested that role-based security was working correctly.

However, the researcher said that this protection existed only in the client-side part of the web app. In simple terms, the page in the browser checked his token, saw that he had no assigned role, and displayed a warning. But the backend APIs, which actually send data to the app, reportedly did not perform the same authorization check. After bypassing the front-end restriction, he said he could reach a streaming management panel connected to the 2026 FIFA World Cup.

The blog claims the panel contained live production information for matches, including multiple camera feeds, preview links, output URLs, and RTMP ingest URLs. An RTMP ingest URL is the address used to send live video into a streaming platform. The researcher wrote that he tested one preview stream in VLC and saw a live tactical feed. He also said stream keys appeared to be shared across several camera angles for the same match, which could have increased the possible impact of any misuse.

The researcher said he tried hard to report the issue and contacted several organizations before it was fixed. He also wrote that the companies involved corrected the problem without replying directly to him. The case is a strong example of a common security lesson: client-side controls are not enough. Sensitive systems need proper authorization checks on the server side, especially when public registration can place outside users into a shared identity environment with access to internal applications.

A security researcher says they found a large malware campaign on GitHub. The problem started when they searched for one of their own projects and saw another repository with the exact same name and description. It looked like a copy of the original project, including its commit history, but a recent change had added a link in the readme file to a zip archive. The researcher later noticed another similar case while checking project tags and found the same pattern again.

After watching these repositories, the researcher said the attackers repeated a strange action every few hours. They deleted the previous commit and pushed the same kind of commit again. In each case, the only visible change was an update to the readme, which included a link to download a zip file. According to the report, the archive contained several files, such as a command script, an executable file, and a DLL file. When the archive was tested as a full zip file, security tools detected a Trojan, which is a type of malicious program that pretends to be safe.

The researcher then tried to find a general pattern instead of checking repositories one by one. Their pattern included several signs: copied commits from another repository, a new repository that was not a fork, frequent replacement of the latest commit, and a readme containing a zip link. They also noted that the repositories used different names and different contributor accounts, which made them harder to find through simple searches. Using this idea, the researcher said they identified around 10,000 repositories that matched the pattern.

The report also raises questions about platform moderation and software supply chain safety. Developers often trust public code hosting sites, especially when a repository looks active and familiar. A cloned project with a convincing history can make a harmful download seem legitimate. For engineers and security teams, this case is a reminder to verify download sources carefully, inspect unexpected readme changes, and scan complete archives rather than only individual files when checking for threats.

A report from Tom’s Hardware says AMD has quietly removed a memory encryption feature from some consumer Ryzen processors after newer AGESA firmware updates. Memory encryption protects data stored in RAM by turning it into unreadable code. This matters because RAM can hold passwords, keys, and other sensitive information while a computer is running. The change was not clearly explained to many users, which raised concern.

AGESA is low-level firmware code that helps a motherboard start the CPU and manage hardware settings. Because it sits below the operating system, changes in AGESA can affect security features without most users noticing. According to the report, the encryption feature disappeared on consumer Ryzen systems after newer firmware versions were installed. When asked about the change, AMD engineers reportedly did not give a clear public explanation.

For average home users, the practical risk may depend on the attack situation. Memory encryption does not stop every kind of attack, but it can reduce the damage if someone tries to read data directly from RAM. In general, this kind of protection is more important in high-security environments, shared systems, or cases where an attacker may get physical access to a machine. Even so, removing a security feature without clear communication can damage trust.

The story also highlights a wider issue in hardware security: features can appear or disappear through firmware updates, not only through new chips. That means buyers cannot always assume that a supported feature will remain available over time. For IT professionals, this is a reminder to review firmware release notes, test security settings after updates, and confirm which protections are active on deployed devices. Clear vendor communication is important when security capabilities change.

Lore is an open source version control system designed for scalability. A version control system is a tool that tracks changes in code and lets teams work on the same project safely. This kind of software is essential in modern programming because developers often work across many repositories, branches, and releases. Lore presents itself as a new option for teams that need strong performance as their codebase and organization grow.

Scalability means a system can continue to work well when the amount of data, the number of users, or the level of activity increases. In version control, this can become difficult when a company has a very large history of changes or many engineers making updates at the same time. A scalable design can reduce delays, improve reliability, and make daily development smoother. For engineering teams, this matters because slow tools can affect productivity and release speed.

Because Lore is open source, developers can study the code, test it, and contribute improvements. This model often helps new infrastructure tools gain trust, especially among technical users who want transparency. It also allows organizations to evaluate whether the system fits their workflow, security needs, and deployment choices. In practice, teams may compare a tool like Lore with existing systems based on performance, collaboration features, and ease of maintenance.

The launch of another version control system shows that core developer tools are still evolving. Even in a mature area of software engineering, there is interest in building systems for larger and more complex environments. For learners and working engineers, Lore is a reminder that foundational tools are not fixed forever. Understanding why scalability matters in source control can help teams choose better architecture and prepare for future growth.

MicroUI is a small user interface library written in ANSI C. It uses an immediate-mode approach, which means the program describes the interface again each frame instead of storing many UI objects for a long time. This design can make a project simpler to understand and easier to control. The GitHub page presents MicroUI as tiny and portable, two qualities that are important for developers working across different systems.

One of the main points of MicroUI is its size. The project says the library is around 1100 source lines of code, which is very small compared with many modern UI frameworks. It also works inside a fixed-sized memory region, so it does not allocate extra memory while running. For developers building lightweight tools, demos, or embedded software, this can be a useful feature because memory use is easier to predict.

MicroUI includes several built-in controls such as windows, scrollable panels, buttons, sliders, textboxes, labels, checkboxes, and wordwrapped text. It also has a simple layout system and is designed so users can add custom controls without too much difficulty. At the same time, the library does not do any drawing by itself. Instead, the user must provide input and process the drawing commands with a rendering system that can draw rectangles and text.

The project is available on GitHub under the MIT license, which allows broad reuse. Its README suggests that the library aims to be a lightweight foundation rather than a feature-heavy framework. Because of that goal, reports about bugs are welcome, but large feature additions may not be accepted. For programmers, MicroUI is interesting not because it tries to do everything, but because it focuses on a small, clear design that can fit many environments.

A recent article argues that many command-line tools still use an old login method that works well on a laptop but fails in remote environments. In the common pattern, a CLI starts a small local HTTP server on 127.0.0.1, opens a browser, and sends the user to an OAuth login page. After the user signs in, the identity provider redirects the browser back to localhost with an authorization code. The CLI then exchanges that code for tokens, often using PKCE, a security feature that protects public clients.

This design is supported for native apps when the device running the app also has a browser. For many developers, the process feels simple because the localhost step is almost invisible. The browser quickly passes through the local callback URL and then moves to a friendly page that says the login is complete. As a result, many users do not notice that the CLI depended on a browser and a local network callback the whole time.

The problem appears when the CLI runs on a remote machine, such as a cloud VM accessed through SSH. In that situation, the host running the CLI may not have a browser at all. A tool may still print a login URL and try to open a browser on the remote system, then wait for a callback that can never arrive. Some tools offer a fallback where the user copies the URL to another device, signs in there, receives a one-time code, and pastes it back into the terminal. It can work, but the article says this feels outdated for modern developer workflows.

The article’s main point is that this is already a solved problem in standards-based authentication, yet many tools have not fully adapted. It highlights a gap between a smooth local experience and real-world engineering work, where remote servers, containers, and development VMs are common. For security teams and tool builders, the lesson is clear: authentication flows should match how developers actually work. A login method that depends on localhost may look elegant, but it becomes fragile when the browser and the CLI are on different machines.

Leaked financial documents reportedly show that OpenAI is still losing billions of dollars each year, even as its revenue grows very quickly. According to reports, the company’s revenue increased strongly from 2024 to 2025, and its monthly revenue was close to $2 billion by the end of 2025. This news came as OpenAI was preparing paperwork with US regulators ahead of an expected public stock offering.

However, the documents suggest that OpenAI’s expenses are growing even faster than its sales. Research and development, often called R&D, was the company’s biggest cost. R&D means the money spent to create and improve new products, including training large AI models. The reports say this expense alone was much higher than total revenue in both 2024 and 2025. A large part of that spending was related to payments for technical infrastructure and model development.

Another major cost was the cost of revenue, which is the money needed to deliver a product or service to users. For an AI company, this can include compute costs during inference time, when a model generates answers to user prompts. As more people use AI tools, these operating costs can rise quickly. Sales and marketing costs also increased sharply, showing that growth in users and customers can be expensive as well.

The reports say OpenAI’s operating loss grew in total dollars, although it became smaller compared with revenue. In other words, the business may be improving in efficiency, but it is still far from making a profit. A much larger net loss in 2025 was also affected by a major accounting charge linked to changes in investor valuations during the company’s move to a for-profit structure. The case shows a bigger question for the AI industry: can fast-growing AI companies reduce model, compute, and pricing costs enough to become sustainably profitable?

As AI tools spread across software teams, some people act as if engineering discipline matters less. They believe AI can quickly write code, tests, and documents, so teams can move faster with fewer rules. But many engineers argue the opposite. When AI produces more code and decisions at higher speed, teams need clearer processes to check quality, safety, and business value.

Engineering discipline means using careful methods to build and maintain systems. It includes code review, testing, documentation, version control, monitoring, and clear ownership. These practices may sound slow, but they reduce errors and confusion over time. AI can generate useful output, but it can also create incorrect answers, hidden risks, or code that looks right while failing in production.

This is especially important in complex systems. A small mistake in one service, prompt, or data pipeline can affect many users. If teams trust AI output too quickly, they may introduce security problems, weak architecture, or technical debt. Technical debt means future work created by fast but poor design choices. Good discipline helps teams verify results, trace changes, and understand why a system behaves in a certain way.

The broader message is not that AI should be avoided. Instead, AI should be used inside a strong engineering culture. Teams still need standards, skilled judgment, and responsibility. AI may change how software is written, but it does not remove the need for reliable systems. In fact, as development becomes more automated, the value of disciplined engineering may become even greater.

A new Scientific American article says the relationship between U.S. science and politics is seriously damaged. It describes a period of confusion, budget pressure, and sudden staffing changes at major research agencies. The article focuses on how this chaos affects long-term scientific projects, especially those that depend on stable government support over many years.

One example is AXIS, a proposed space telescope designed to study the early universe, including the first black holes and the formation of galaxies. The project used advanced x-ray mirrors made of single-crystal silicon, a material engineered for high precision. In 2024, the team received a grant from NASA to improve the idea. Researchers then worked with engineers at NASA Goddard to develop the mission further.

But the project soon faced major disruption. According to the article, NASA lost thousands of employees after a broad package of buyouts, paid leave, and early retirement. The AXIS team lost key people, including engineers and managers. As a result, researchers had to continue with incomplete information and old presentation files. Later, budget cuts proposed by President Donald Trump created even more uncertainty, and some teams were reassigned based on the proposed budget before Congress made final decisions.

The larger issue is not only one telescope. In the U.S., the federal government provides a large share of funding for basic research, which means early-stage science that may not have immediate business value. When programs are cut or delayed, projects can fall behind, experts can leave, and new discoveries may never happen. The article suggests that science needs steady planning, clear priorities, and political support if the country wants to keep building future innovation.

A recent post on Salvaged Circuitry describes the repair and analysis of a Sigma 45mm f/2.8 lens from the company’s I-series. The writer says he only buys heavily discounted lenses that are already broken, hoping to repair them at low cost. In this case, the lens looked almost perfect when it arrived. There were no visible scratches on the barrel, which is the outer body, or on the glass elements. However, appearance did not match performance.

After mounting the lens on a Lumix S5 camera, the writer found a clear electrical problem. The camera started normally and showed a live image, but the lens controls did not respond. The dials and switches on the lens did nothing, and camera controls also failed to register movement from the lens. The lens mount also felt unusually stiff when attached. This suggested that the fault was not optical or mechanical on the surface, but likely related to internal electronics near the rear contact area.

The post explains that the barriers to entry for this kind of repair are fairly low. Most of the required tools are standard and easy to find, such as lens cleaning wipes, microfiber cloths, nitrile gloves, a magnifier, and small screwdrivers. The writer also notes that many camera products use JIS screws, a Japanese screw standard, and says using the correct driver helps avoid damaging the screw heads. Clean filtered air is useful for removing dust before opening sensitive hardware.

For disassembly, the writer follows a careful process and keeps each screw in a matched orientation to make reassembly easier. First, a rear plastic beauty spacer is removed, followed by several machine screws and screws that hold the terminal interface to the metal mount. Although the source context only shows the early part of the teardown, the post is a useful example of practical hardware debugging. It shows how a device can look excellent from the outside while still having a serious internal fault, and why methodical inspection matters in repair work.