Docker Images Containing Cryptojacking Malware Distributed via Docker Hub

With Docker gaining popularity as a service to package and deploy software applications, malicious actors are taking advantage of the opportunity to target exposed API endpoints and craft malware-infested images to facilitate distributed denial-of-service (DDoS) attacks and mine cryptocurrencies.

According to a report published by Palo Alto Networks' Unit 42 threat intelligence team, the purpose of these Docker images is to generate funds by deploying a cryptocurrency miner using Docker containers and leveraging the Docker Hub repository to distribute these images.

"Docker containers provide a convenient way for packaging software, which is evident by its increasing adoption rate," Unit 42 researchers said. "This, combined with coin mining, makes it easy for a malicious actor to distribute their images to any machine that supports Docker and instantly starts using its compute resources towards cryptojacking."

Docker is a well-known platform-as-a-service (PaaS) solution for Linux and Windows that allows developers to deploy, test, and package their applications in a contained virtual environment — in a way that isolates the service from the host system they run on.

The now taken down Docker Hub account, named "azurenql," consisted of eight repositories hosting six malicious images capable of mining Monero, a privacy-focused cryptocurrency.

The malware author behind the images used a Python script to trigger the cryptojacking operation and took advantage of network anonymizing tools such as ProxyChains and Tor to evade network detection.

The coin mining code within the image then exploited the processing power of the infected systems to mine the blocks.

The images hosted on this account have been collectively pulled over ​two million times​ since the start of the campaign in October 2019, with one of the wallet IDs used to earn more than 525.38 XMR ($36,000).

Exposed Docker Servers Targeted With DDoS Malware

That's not all. In a new mass-scanning operation spotted by Trend Micro researchers, unprotected Docker servers are being targeted with at least two different kinds of malware — XOR DDoS and Kaiji — to collect system information and carry out DDoS attacks.

"Attackers usually used botnets to perform brute-force attacks after scanning for open Secure Shell (SSH) and Telnet ports," the researchers said. "Now, they are also searching for Docker servers with exposed ports (2375)."

It's worth noting that both XOR DDoS and Kaiji are Linux trojans known for their ability to conduct DDoS attacks, with the latter written entirely from scratch using Go programming language to target IoT devices via SSH brute-forcing.

The XOR DDoS malware strain works by searching for hosts with exposed Docker API ports, followed by sending a command to list all the containers hosted on the target server, and subsequently compromising them with the XORDDoS malware.

Likewise, the Kaiji malware scans the internet for hosts with exposed port 2375 to deploy a rogue ARM container ("linux_arm") that executes the Kaiji binary.

"While the XOR DDoS attack infiltrated the Docker server to infect all the containers hosted on it, the Kaiji attack deploys its own container that will house its DDoS malware," the researchers said, noting the difference between the two malware variants.

In addition, both the two pieces of malware gather details such as domain names, network speeds, process identifiers of running processes, and CPU and network information that are needed to mount a DDoS attack.

"Threat actors behind malware variants constantly upgrade their creations with new capabilities so that they can deploy their attacks against other entry points," the researchers concluded.

"As they are relatively convenient to deploy in the cloud, Docker servers are becoming an increasingly popular option for companies. However, these also make them an attractive target for cybercriminals who are on the constant lookout for systems that they can exploit."

It's advised that users and organizations who run Docker instances immediately check if they expose API endpoints on the Internet, close the ports, and adhere to recommended best practices.

Source :

High Severity Vulnerabilities in PageLayer Plugin Affect Over 200,000 WordPress Sites

A few weeks ago, our Threat Intelligence team discovered several vulnerabilities present in Page Builder: PageLayer – Drag and Drop website builder, a WordPress plugin actively installed on over 200,000 sites. The plugin is from the same creators as wpCentral, a plugin within which we recently discovered a privilege escalation vulnerability.

One flaw allowed any authenticated user with subscriber-level and above permissions the ability to update and modify posts with malicious content, amongst many other things. A second flaw allowed attackers to forge a request on behalf of a site’s administrator to modify the settings of the plugin which could allow for malicious Javascript injection.

We initially reached out to the plugin’s developer on April 30, 2020 and after establishing an appropriate communication channel, we provided the full disclosure on May 1, 2020. They responded quickly on May 2, 2020 letting us know that they were beginning to work on fixes. An initial patch was released on May 2, 2020 and an optimal patch was released on May 6, 2020.

These are considered high-level security issues that could potentially lead to attackers wiping your site’s content or taking over your site. We highly recommend an immediate update to the latest version available at the time of this publication, which is version 1.1.4.

Wordfence Premium customers received a new firewall rule on April 30, 2020, to protect against exploits targeting this vulnerability. Free Wordfence users will receive this rule after thirty days, on May 30, 2020.

Description: Unprotected AJAX and Nonce Disclosure to Stored Cross-Site Scripting and Malicious Modification
Affected PluginPage Builder: PageLayer – Drag and Drop website builder
Plugin Slug: pagelayer
Affected Versions: <= 1.1.1
CVE ID: Will be updated once identifier is supplied.
CVSS Score: 7.4 (High)
Fully Patched Version: 1.1.2

PageLayer is a very easy to use WordPress page builder plugin that claims to work with nearly all themes on the market and in the WordPress repository. It provides extended customization of pages through the use of widgets that can add page elements like buttons, tables, excerpts, products and more.

We discovered that nearly all of the AJAX action endpoints in this plugin failed to include permission checks. This meant that these actions could be executed by anyone authenticated on the site, including subscriber-level users. As standard, these AJAX endpoints only checked to see if a request was coming from /wp-admin through an authenticated session and did not check the capabilities of the user sending the request.

There were nonce checks in use in all of these functions, but nonces can be easily compromised if incorrectly implemented – for example, if a usable nonce is displayed within the source code of the site’s output. Unfortunately for the PageLayer plugin, this is precisely what happened. A usable nonce was visible in the header section of the source code of any page that had previously been edited using the PageLayer plugin. Any site visitor could find this nonce, whether they were logged in or not, allowing any unauthenticated user the ability to obtain a legitimate nonce for the plugin’s AJAX actions.

PageLayer nonce obtainable from page source.

Using a single nonce as the mechanism for authorization control caused various security issues in the functionalities of the page builder due to this nonce being so easily obtainable.

WordPress nonces should never be used as a means of authorization as they can easily be compromised if implemented improperly or if a loophole is found. WordPress nonces are designed to be used for CSRF protection, not authorization control. Implementing capability checks in conjunction with CSRF protection on sensitive functions for full verification provides protection to ensure a request is coming from an authorized user.

The Impact

As previously mentioned, several AJAX functions were affected, causing a large variety of potential impacts. A few of the most impactful actions were wp_ajax_pagelayer_save_contentwp_ajax_pagelayer_update_site_title, and wp_ajax_pagelayer_save_template.

add_action('wp_ajax_pagelayer_save_content', 'pagelayer_save_content');
add_action('wp_ajax_pagelayer_update_site_title', 'pagelayer_update_site_title');
add_action('wp_ajax_pagelayer_save_template', 'pagelayer_save_template');

The pagelayer_save_content function is used to save a page’s data through the page builder. The lack of permission checks on this function allowed authenticated users, regardless of permissions, the ability to change any data on a page edited with PageLayer.

function pagelayer_save_content(){
    // Some AJAX security
    check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');
    $content = $_POST['pagelayer_update_content'];
    $postID = (int) $_GET['postID'];
        $msg['error'] =  __pl('invalid_post_id');

An attacker could wipe the pages completely or inject any content they would like on the site’s pages and posts. In addition, a few widgets allowed Javascript to be injected, including the “Button” widget. There is no sanitization on the “Button” widget’s text, which allows for malicious Javascript to be used as a text. This Javascript would execute once any user browsed to a page containing that button.

PageLayer button with alert JS injected.

The pagelayer_update_site_title function is used to update a site’s title. The lack of permission checks on this function allowed authenticated users the ability to change a site title to any title of their choosing. Though less detrimental, this could still affect your sites search engine ranking if unnoticed for an extended period of time.

function pagelayer_update_site_title(){
    global $wpdb;
    // Some AJAX security
    check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');
    $site_title = $_POST['site_title'];
    update_option('blogname', $site_title);
    $wpdb->query("UPDATE `sm_sitemeta`
                SET meta_value = '".$site_title."'
                WHERE meta_key = 'site_name'");

The pagelayer_save_template function is used to save PageLayer templates for the PageLayer Theme Builder. The lack of permission checks on this function allowed authenticated users the ability to create new PageLayer templates that were saved as new posts.

function pagelayer_save_template() {
    // Some AJAX security
    check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');
    $done = [];
    $post_id = (int) $_GET['postID'];
    // We need to create the post
        // Get the template type
            $done['error'] = __pl('temp_error_type');
        $ret = wp_insert_post([
            'post_title' => $_POST['pagelayer_lib_title'],
            'post_type' => 'pagelayer-template',
            'post_status' => 'publish',
            'comment_status' => 'closed',
            'ping_status' => 'closed'

Though this function was intended to be used in the PRO version of the plugin, the function could still be executed in the free version, affecting all 200,000+ users of the PageLayer plugin. An attacker could create a new template, which created a new page on the site, and inject malicious Javascript in the same way they could with the pagelayer_save_content function.

Malicious Javascript can be used to inject new administrative users, redirect site visitors, and even exploit a site’s user’s browser to compromise their computer.

The Patch

In the latest version of the plugin, the developers implemented permissions checks on all of the sensitive functions that could make changes to a site, and reconfigured the plugin to create separate nonces for the public and administrative areas of a WordPress site.

// Are you allowed to edit ?
    $msg['error'][] =  __pl('no_permission');
Description: Cross-Site Request Forgery to Stored Cross-Site Scripting
Affected PluginPage Builder: PageLayer – Drag and Drop website builder
Plugin Slug: pagelayer
Affected Versions: <= 1.1.1
CVE ID: Will be updated once identifier is supplied.
CVSS Score: 8.8 (High)
Fully Patched Version: 1.1.2

The PageLayer plugin registers a settings area where configuration changes can be made. This includes functionality such as where the editor is enabled, basic content settings, basic information configurations, and more.

PageLayer settings area.

The settings update function used a capability check to verify that a user attempting to make any changes had the appropriate permissions. However, there was no CSRF protection to verify the legitimacy of any request attempting to update a site’s settings. This made it possible for attackers to trick an administrator into sending a request to update any of the PageLayer settings.

function pagelayer_settings_page(){
    $option_name = 'pl_gen_setting' ;
    $new_value = '';
        $new_value = $_REQUEST['pl_gen_setting'];
        if ( get_option( $option_name ) !== false ) {
            // The option already exists, so we just update it.
            update_option( $option_name, $new_value );

The “Information” tab in the settings area provides site owners with a way to set a default address, telephone number, and contact email address that are displayed whenever the corresponding widgets were used on a page. There was no sanitization on the address or telephone number settings, and due to the administrator’s capability to use unfiltered_html, Javascript could be injected into these settings.

PageLayer Address updated with alert JS.

The Impact

This allowed attackers the ability to inject malicious scripts while exploiting the CSRF vulnerability in the settings. If the widget was already enabled, any injected malicious scripts would execute whenever someone browsed to a page containing that widget. If the widget was not yet enabled, the malicious scripts could be executed once an administrator started editing and inserting the widget into a page. As always, these scripts can do things like create a new administrative account and redirect users to malicious sites.

The Patch

In the patched version of the plugin, the developers implemented CSRF protection consisting of a WordPress nonce and verification of that nonce when updating settings.


PoC Walkthrough: pagelayer_save_content

Disclosure Timeline

April 24, 2020 to April 30, 2020 – Initial discovery of minor security flaw and deeper security analysis of plugin.
April 30, 2020 – Firewall rule was released for Wordfence Premium customers. We made our initial contact attempt with the plugin’s development team.
May 1, 2020 – The plugin’s development team confirms appropriate inbox for handling discussion. We provide full disclosure.
May 2, 2020 – Developer acknowledges receipt and confirms that they are beginning to work on fixes. An update is released the same day.
May 4, 2020 – We analyze the fixes and discover a few security issues left unpatched and responsibly disclose these issues to the developer.
May 6, 2020 – Developer releases the final sufficient patch.
May 30, 2020 – Free Wordfence users receive firewall rule.


In today’s post, we detailed several flaws related to unprotected AJAX actions and nonce disclosure that allowed for attackers to make several malicious modifications to a site’s pages and posts in addition to providing attackers with the ability to inject malicious Javascript. These flaws have been fully patched in version 1.1.2. We recommend that users immediately update to the latest version available, which is version 1.1.4 at the time of this publication.

Sites running Wordfence Premium have been protected from attacks against this vulnerability since April 30, 2020. Sites running the free version of Wordfence will recieve this firewall rule update on May 30, 2020. If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected.

Source :

Large Scale Attack Campaign Targets Database Credentials

Between May 29 and May 31, 2020, the Wordfence Firewall blocked over 130 million attacks intended to harvest database credentials from 1.3 million sites by downloading their configuration files.

The peak of this attack campaign occurred on May 30, 2020. At this point, attacks from this campaign accounted for 75% of all attempted exploits of plugin and theme vulnerabilities across the WordPress ecosystem.

We were able to link these attacks to the same threat actor previously targeting XSS vulnerabilities at a similar scale. All Wordfence users, including Wordfence Premium and those still using the free version of Wordfence, are protected by our firewall’s built-in directory traversal protection.

Different vulnerabilities, same IPs

The previously reported XSS campaigns sent attacks from over 20,000 different IP addresses. The new campaign is using the same IP addresses, which accounted for the majority of the attacks and sites targeted. This campaign is also attacking nearly a million new sites that weren’t included in the previous XSS campaigns.

As with the XSS campaigns, almost all of the attacks are targeted at older vulnerabilities in outdated plugins or themes that allow files to be downloaded or exported. In this case the attackers are attempting to download wp-config.php, a file critical to all WordPress installations which contains database credentials and connection information, in addition to authentication unique keys and salts. An attacker with access to this file could gain access to the site’s database, where site content and users are stored.

Indicators of Compromise

Attacks by this campaign should be visible in your server logs. Look for any log entries containing wp-config.php in the query string that returned a 200 response code.

The top 10 attacking IP addresses in this campaign are listed below.

What should I do?

Sites running Wordfence are protected against this campaign. If your site is not running Wordfence, and you believe you have been compromised, change your database password and authentication unique keys and salts immediately.

If your server is configured to allow remote database access, an attacker with your database credentials could easily add an administrative user, exfiltrate sensitive data, or delete your site altogether. Even if your site does not allow remote database access, an attacker who knows your site’s authentication keys and salts may be able to use them to more easily bypass other security mechanisms.

If you’re not comfortable making the changes above, please contact your host, since changing your database password without updating the wp-config.php file can temporarily take down your site.


In today’s post, we covered another large-scale attack campaign against WordPress sites by a threat actor we have been tracking since February. All Wordfence users, including sites running the free version of Wordfence, and Wordfence Premium, are protected against these attacks. Nonetheless, we urge you to make sure that all plugins and themes are kept up to date, and to share this information with any other site owners or administrators you know. Attacks by this threat actor are evolving and we will continue to share additional information as it becomes available.

Source :

WordPress 5.4.2 Patches Multiple XSS Vulnerabilities

WordPress Core version 5.4.2 has just been released. Since this release is marked as a combined security and bug fix update, we recommend updating as soon as possible. With that said, most of the security fixes themselves are for vulnerabilities that would require specific circumstances to exploit. All in all this release contains 6 security fixes, 3 of which are for XSS (Cross-Site Scripting) vulnerabilities. Both the free and Premium versions of Wordence have robust built-in XSS protection which will protect against potential exploitation of these vulnerabilities.

A Breakdown of each security issue

An XSS issue where authenticated users with low privileges are able to add JavaScript to posts in the block editor

This flaw would have made it possible for an attacker to inject JavaScript into a post by manipulating the attributes of Embedded iFrames. This would be exploitable by users with the edit_posts capability, meaning users with the Contributor role or higher in most configurations.

The changeset in question is:

This issue was discovered and reported by Sam Thomas (jazzy2fives)

An XSS issue where authenticated users with upload permissions are able to add JavaScript to media files

This flaw would have made it possible for an attacker to inject JavaScript into the “Description” field of an uploaded media file. This would be exploitable by users with the upload_files capability, meaning users with the Author role or higher in most configurations.

The changeset in question is:

This issue was discovered and reported by Luigi – (

An open redirect issue in wp_validate_redirect()

For this flaw, the wp_validate_redirect function failed to sufficiently sanitize URLs supplied to it. As such it would have been possible under certain circumstances for an attacker to craft a link to an impacted site that would redirect visitors to a malicious external site. This would not require specific capabilities, but it would typically require either social engineering or a separate vulnerability in a plugin or theme to exploit.

The changeset in question is:

This issue was discovered and reported by Ben Bidner of the WordPress Security Team.

An authenticated XSS issue via theme uploads

This flaw would have made it possible for an attacker to inject JavaScript into the stylesheet name of a broken theme, which would then be executed if another user visited the Appearance->Themes page on the site. This would be exploitable by users with the install_themes or edit_themes capabilities, which are only available to administrators in most configurations.

The changeset in question is:

This issue was discovered and reported by Nrimo Ing Pandum

An issue where set-screen-option can be misused by plugins leading to privilege escalation

For this flaw, a plugin incorrectly using the set-screen-option filter to save arbitrary or sensitive options could potentially be used by an attacker to gain administrative access. We are not currently aware of any plugins that are vulnerable to this issue.

The changeset in question is:

This issue was discovered and reported by Simon Scannell of RIPS Technologies

An issue where comments from password-protected posts and pages could be displayed under certain conditions

For this flaw, comment excerpts on password-protected posts could have been visible on sites displaying the “Recent Comments” widget or using a plugin or theme with similar functionality.

The changeset in question is:

This issue was discovered and reported by Carolina Nymark

Note: This is unrelated to an issue where unmoderated spam comments were briefly visible and indexable by search engines.

What should I do?

Most of these vulnerabilities appear to be exploitable only under limited circumstances or by trusted users, but we recommend updating as soon as possible. Attackers may find ways to exploit them more easily, or the researchers who discovered these vulnerabilities may publish Proof of Concept code that allows simpler exploitation. This is a minor WordPress release, so most sites will automatically update to the new version.


We’d like to thank the WordPress core team and the researchers who discovered and responsibly reported these vulnerabilities for making WordPress safer for everyone.

You can find the official announcement of the WP 5.4.2 release on this page. If you have any questions or comments, please don’t hesitate to post them below and we’ll do our best to answer them in a timely manner. If you are one of the researchers whose work is included above and would like to provide additional detail or corrections, we welcome your comments.

Source :

Australian researchers record world’s fastest internet speed from a single optical chip

Researchers from Monash, Swinburne and RMIT universities have successfully tested and recorded Australia’s fastest internet data speed, and that of the world, from a single optical chip – capable of downloading 1000 high definition movies in a split second.

Published in the prestigious journal Nature Communications, these findings have the potential to not only fast-track the next 25 years of Australia’s telecommunications capacity, but also the possibility for this home-grown technology to be rolled out across the world.

In light of the pressures being placed on the world’s internet infrastructure, recently highlighted by isolation policies as a result of COVID-19, the research team led by Dr Bill Corcoran (Monash), Distinguished Professor Arnan Mitchell (RMIT) and Professor David Moss (Swinburne) were able to achieve a data speed of 44.2 Terabits per second (Tbps) from a single light source.

This technology has the capacity to support the high-speed internet connections of 1.8 million households in Melbourne, at the same time, and billions across the world during peak periods.

Demonstrations of this magnitude are usually confined to a laboratory. But, for this study, researchers achieved these quick speeds using existing communications infrastructure where they were able to efficiently load-test the network.

They used a new device that replaces 80 lasers with one single piece of equipment known as a micro-comb, which is smaller and lighter than existing telecommunications hardware. It was planted into and load-tested using existing infrastructure, which mirrors that used by the NBN.

The micro-comb chip over a A$2 coin. This tiny chip produces an infrared rainbow of light, the equivalent of 80 lasers. The ribbon to the right of the image is an array of optical fibres connected to the device. The chip itself measures about 3x5 mm.

It is the first time any micro-comb has been used in a field trial and possesses the highest amount of data produced from a single optical chip.

“We’re currently getting a sneak-peak of how the infrastructure for the internet will hold up in two to three years’ time, due to the unprecedented number of people using the internet for remote work, socialising and streaming. It’s really showing us that we need to be able to scale the capacity of our internet connections,” says Dr Bill Corcoran, co-lead author of the study and Lecturer in Electrical and Computer Systems Engineering at Monash University.

“What our research demonstrates is the ability for fibres that we already have in the ground, thanks to the NBN project, to be the backbone of communications networks now and in the future. We’ve developed something that is scalable to meet future needs.

“And it’s not just Netflix we’re talking about here – it’s the broader scale of what we use our communication networks for. This data can be used for self-driving cars and future transportation and it can help the medicine, education, finance and e-commerce industries, as well as enable us to read with our grandchildren from kilometres away.”

To illustrate the impact optical micro-combs have on optimising communication systems, researchers installed 76.6km of ‘dark’ optical fibres between RMIT’s Melbourne City Campus and Monash University’s Clayton Campus. The optical fibres were provided by Australia’s Academic Research Network.

Within these fibres, researchers placed the micro-comb – contributed by Swinburne, as part of a broad international collaboration – which acts like a rainbow made up of hundreds of high quality infrared lasers from a single chip. Each ‘laser’ has the capacity to be used as a separate communications channel.

Researchers were able to send maximum data down each channel, simulating peak internet usage, across 4THz of bandwidth.

Distinguished Professor Mitchell said reaching the optimum data speed of 44.2 Tbps showed the potential of existing Australian infrastructure. The future ambition of the project is to scale up the current transmitters from hundreds of gigabytes per second towards tens of terabytes per second without increasing size, weight or cost.

“Long-term, we hope to create integrated photonic chips that could enable this sort of data rate to be achieved across existing optical fibre links with minimal cost,” Distinguished Professor Mitchell says.

“Initially, these would be attractive for ultra-high speed communications between data centres. However, we could imagine this technology becoming sufficiently low cost and compact that it could be deployed for commercial use by the general public in cities across the world.”

Professor Moss, Director of the Optical Sciences Centre at Swinburne, says: “In the 10 years since I co-invented micro-comb chips, they have become an enormously important field of research.

“It is truly exciting to see their capability in ultra-high bandwidth fibre optic telecommunications coming to fruition. This work represents a world-record for bandwidth down a single optical fibre from a single chip source, and represents an enormous breakthrough for part of the network which does the heaviest lifting. Micro-combs offer enormous promise for us to meet the world’s insatiable demand for bandwidth.”

To download a copy of the paper, please visit:

Source :

World Record Transmission of 172 Terabit/s over 2,040 km Distance Coupled-3-core Multi-core Fiber

  • A world record for high-capacity, long-haul transmission in standard diameter optical fibers was achieved in coupled-3-core multi-core fiber with characteristics similar to multi-mode fibers.
  • The signal processing complexity is significantly reduced compared to multi-mode fibers.
  • The fiber type is promising for early adoption in backbone high-capacity transmission systems as it can be cabled with the same technology.
In a collaboration, led by RADEMACHER Georg between researchers from the Network Systems Research Institute at the National Institute of Information and Communications Technology (NICT, President: TOKUDA Hideyuki, Ph.D.) and researchers from NOKIA Bell Labs (Bell Labs, President: WELDON Marcus), led by RYF Roland, transmission of 172 terabit/s over 2,040 km was successfully demonstrated, using a standard outer diameter (0.125 mm) coupled-3-core optical fiber.
Using the product of data-rate and distance as a general index of transmission capacity, we achieved 351 petabit/s x km, more than doubling the current world record in standard outer diameter optical fibers employing space-division multiplexing. The used coupled-core multi-core fiber requires signal processing on the receiving side after transmission, but the signal processing load is less compared to more commonly investigated few-mode fibers. In addition, the used fiber has the same outer diameter as standard optical fibers which allows to convert such a fiber into a cable with existing technologies and equipment, simplifying a timely adoption of coupled-core multi-core fibers in the industry.
     The results of this experiment were presented at the 43rd International Conference on Optical Fiber Communications (OFC 2020) where it was accepted as a Post Deadline Paper.


Figure 1: Data-rates and distances reported to date with standard cladding diameter optical fibers
In order to cope with ever-increasing communication traffic, research on new-types of optical fibers that can exceed the limits of conventional optical fibers and large-scale optical transmission experiments using them are actively conducted around the world. In research pursuing ultimate high capacity, multi-core and multi-mode fibers that increase the number of optical fiber cores and transmit optical signals of different modes to each core are being studied. On the other hand, in research aimed at early commercialization, research is being carried out on multi-core or multi-mode optical fibers with a standard outer diameter (0.125 mm) in consideration of manufacturing methods and ease of handling.


NICT constructed a large-capacity, long-distance transmission system based on the results of Bell Labs' long-distance transmission demonstration experiment using the suppressed modal dispersion characteristics of a coupled-core multi-core fiber. 359 wavelength channels were modulated by 16QAM signals, and a total data-rate of 172 terabits per second was successfully transmitted over 2,040 km. Converted to the product of transmission capacity and distance, which is a general indicator of transmission capacity, 351 petabit per second x km was achieved, which is more than twice the current world record.
When using coupled-core multi-core fibers for transmission, it is necessary to eliminate the interference between optical signals between cores by signal processing (MIMO processing) on the receiving side. To date, transmission over coupled-core multi-core fibers has been performed only in a limited signal band (less than 5 nanometers in wavelength range), and it was unclear whether it is possible to achieve both long-distance transmission characteristics and large-capacity transmission in coupled-core multi-core fibers.
In this experiment, using a standard outside diameter optical fiber, we succeeded in transmitting 17 times the backbone communication capacity of Japan over a distance of 2,040 km. The standard outside diameter optical fiber is compatible with conventional fiber cables, increasing prospects for early commercialization of large-capacity backbone communication systems.
Figure 2: Experimental demonstrations of advanced optical fibers by NICT

Future Prospects

We will work on research and development of future optical communication infrastructure technology that can smoothly accommodate traffic such as 5G-based services and international communications via submarine cables.
The paper on the results of this experiment was published at the 43rd International Conference on Optical Fiber Communication (OFC 2020, March 8 (Sun) - March 12 (Thu)), one of the largest international conferences on optical fiber communication held in San Diego, USA. It was highly evaluated and was presented in the Post Deadline session, known for release of latest important research achievements, and published on Thursday, March 12 2020.


International Conference: 43rd International Conference on Optical Fiber Communications (OFC 2020) Post Deadline Paper
Title: 172 Tb/s C+L Band Transmission over 2,040 km Strongly Coupled 3-Core Fiber
Authors: Georg Rademacher, Ruben S. Luís, Benjamin J. Puttnam, Roland Ryf, Sjoerd v. d. Heide, Tobias A. Eriksson, Nicolas K. Fontaine, Haoshuo Chen, René-Jean Essiambre, Yoshinari Awaji, Hideaki Furukawa, and Naoya Wada

Source :